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ARCHITECTURE FOR MULTIPLE CHANNEL ACCESS 

TO APPLICATIONS 

5 

Field of the Invention 

The present invention relates to computer 
systems and, more particularly, to methods and 
systems for the integration of multiple types of 
10 devices for accessing Internet based applications. 

Background to the Invention 

The growth of interest and participation in 
the Internet has led to a clamor for more ways of 

15 accessing Internet based applications. Consumers now 

use the Internet for tasks which a mere five years 
ago were considered to be the sole territory of the 
personal computer, Web based applications now allow 
people to store, access, modify, and retrieve, among 

20 others, their calendars, bank transactions, e-mail, 

telephone messages, appointments, and contact lists 
through the Internet. These same consumers now want 
the ability to access these Internet based 
applications anywhere using physically smaller 

25 devices. Of course, this must be done without 

compromising the lowest common denominator among most 
consumers — the personal computer (PC) based 
Internet browser. Accordingly, any solution must 
preserve the Internet application's workstation 

30 centric core. However, at the same time these 

applications should also allow such diverse devices 
as WAP (Wireless Application Protocol) enabled mobile 
telephones, palmtop computers, regular telephones, 
and personal digital assistants (PDAs) to access its 

35 functions. 
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To answer the above need, a number of 
solutions have been attempted with mixed results. 
Web based applications have been customized to run on 
these smaller devices with the devices accessing them 
5 through specific web portals. Such an approach is, 

unfortunately, quite expensive. Not only is a 
rewrite of the application required for each and 
every device type, there is also no guarantee that 
the rewritten application will have the functions of 

10 the original application. 

Another attempted solution is the shrinking 
of web browsers so that they can run on these 
devices. Unfortunately, the applications, optimized 
for PCs, are not suitable for such an approach. The 

15 small screen (if any) and the limited capabilities of 

the devices have led to consumer frustration with 
this approach. Furthermore, the relatively slow 
speed of the connection between the device and the 
portal, normally through a wireless modem, also leads 

20 to consumer frustration. 

Another drawback to such devices is the 
lack of scripting capability of the browsers of such 
devices. A further wrinkle to the problem is the 
need to customize each attempted solution to a 

25 specific device platform. A solution which may work 

properly with a WAP enabled cellular telephone may 
not work properly with a PDA and vice versa. Also, 
what may work with a cellular telephone is almost 
guaranteed not to work with a regular telephone 

30 connected to a PSTN (public switched telephone 

network) . 

A suitable solution to the above should be 
flexible, scalable, and must work equally well with 
any and all devices which are currently being used to 
35 access the Internet. Such a solution should also be 
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transparent to the user and should facilitate rather 
than hamper a user's access to the Internet 
application. 

5 • Summary of the Invention 

The present invention provides systems and 
methods which allow an Internet based application to 
be accessed by any device capable of accessing a 
specific portal without requiring an intensive 

10 rewriting of the application. Indeed, while an API is 

desirable, no access to the application's source code 
or application programming interface (API ) is 
required. A three layered system is placed between 
the application and the accessing device. The first 

15 layer is an AMI (Application Mediation Interface) 

component directly connected with the application. 
This application component is able to directly access 
any data stored by the application. A second layer 
is a broker layer which mimics the general user 

20 interface logic of the application. The broker layer 

emulates the UI (User Interface) workflow of the 
application and, when required, requests data from 
the application through the application component. 
The third layer is a DMI (Device Mediation Interface) 

25 component which communicates directly with the end 

user device. The DMI component receives data from the 
broker layer and converts this data into user 
interfaces, data screens, or prompt screens which the 
end user device can both understand and present to 

30 the end user. 

In a first aspect the present invention 
provides a system for enabling multiple types of end 
user devices to access an application, said system 
comprising: 

35 - an AMI (Application Mediation Interface) 
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component communicating with said application; 

- a DMI (Device Mediation Interface) component 
communicating with said devices; and 

- a broker module communicating with said DMI 
5 component and with said AMI component, 

wherein 

- said DMI component converts end data received 
from said broker module into a format suitable 
for said devices; 

- said DMI component transmits replies to 
prompts from said broker module based on an end 
user's input into said devices; 

- said broker module emulates a sequence of 
events and decisions followed by said 
application; 

- said broker module provides application data 
functions from said AMI component based on said 
broker module emulating said application; 

- said AMI component receives requests from said 
broker module and transmits replies to said 
requests to said broker module based on original 
data from said application; and 

- said broker module transmits end data to said 
DMI component, said end data being based on at 
least one factor chosen from the group 
comprising: 

- said broker module's emulation of said 
application; and 

- application data received from said AMI 
component . 

In a second aspect the present invention 
provides a method of enabling multiple types of end 
user devices to access an application, said method 
comprising: 

- emulating a sequence of events and decisions 
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followed by said application at a broker module 

- requesting application data from an AMI 
(Application Mediation Interface) component 
based on an emulation of said application by 

5 said broker module, said AMI component 

communicating with said application; 

- transmitting application data requested to 
said broker module from said application server, 
said application data being based on original 

10 data received from said application by said AMI 

component , and 

" transmitting end data to a DMI (device 
Mediation Interface) component, said end data 
being based on at least one factor chosen from 
15 the group comprising: 

- said broker module's emulation of said 
application; 

- application data received from said AMI 
component ; 

20 - converting said end data at said DMI 

component into a format suitable for an end 
user device communicating with said DMI 
component . 


25 Brief Description of the Diagrams 

A better understanding of the invention may 

be obtained by reading the detailed description of 

the invention below, in conjunction with the 

following drawings, in which: 
30 Figure 1 is a block diagram of a system 

according to the invention; 

Figure 2 is a block diagram similar to 

figure 1 but with multiple broker modules and 

multiple applications; and 
35 Figure 3 is a detailed block diagram of the 


15 
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system whose implementation is described below. 

Detailed Description of the Preferred Embodiment 

Referring to Figure 1, a block diagram of 
5 a system in accordance with the invention is 

illustrated. An Internet based application 10 
communicates with an AMI (Application Mediation 
Interface) component 20. Coupled to the AMI 
component is a broker module 30 which, in turn, is 
10 coupled to a DMI (Device Mediation Interface) 

component 40. The DMI component 40 communicates with 
an end user device 50. The broker module 30 is 
unique to each application as it reproduces the 
workflow or the top level logic of the application 
10. However, the AMI component 20 abstracts the data 
of the application 10 so that, when required, the 
broker module may request application data from the 
application 10 through the AMI component 20. This 
application data is then converted and/or added to by 
the broker module prior to being passed on to the DMI 
component 40. The DMI component 40 is equipped to 
receive this end data and convert such data into a 
format suitable for whichever end user device is 
connected to it. 
25 The above scheme does not compromise the 

Internet capability of the application 10. As can be 
seen in Fig 2, the invention can accommodate multiple 
applications, multiple end user devices, and still 
allow regular personal computers access to the 
applications. From Fig 2, multiple applications lOA, 
lOB, IOC, and lOD are communicating with the AMI 
component 20. For each application, a separate 
broker module is available. Broker 30A corresponds 
to application lOA, broker 3 OB corresponds to 
application 30B, broker 30C and broker 30D correspond 


20 


30 


35 
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to applications C and D respectively* Also, multiple 
devices can be connected to the DMI component* 
Device 50A is a palmtop PC, device SOB is a WAP 
enabled cellular phone, device 50C is a telephone 
5 connected to a PSTN, and device 50D is a PDA, The 

Internet 60 also connects a regular PC 70 with the 
applications lOA-lOD. 

It should be noted that each of the end 
user devices 50A-50D communicate differently with the 

10 DMI component and each one requires a different data 

format* The palmtop PC can be connected by means of 
a regular modem while the PDA can be connected by a 
wireless modem. The WAP cellphone can be connected 
by its wireless link to the service provider while 

15 the telephone 50C is connected by a regular telephone 

line and a suitable interface* 

In a specific implementation, the broker 
module functions are accomplished by the use of a 
script written in an XML (extended markup language) 

20 derived markup language MCML (multi-channel mark up 

language) . Each script follows and details the 
workflow of the application for which it is written. 
When required, the script, through a machine running 
it, calls for data from the AMI component. The 

25 script is device independent and AMI component 

independent. However, as noted above, it details the 
workflow or top level logic (events and decisions) of 
the application. Thus, the script will have the user 
prompts, the choices associated with such prompts, 

30 user input fields, data delivery, and the flow 

decisions associated with such options. The script, 
will, however, not mimic the deep functions of the 
application. It is simply a data delivery mechanism 
— it prompts, receives, and delivers data to the end 

35 user through the DMI component. To do this, it 


I 
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requests and receives data from the AMI component. 
It then reformats and/or adds to the data before 
sending it on to the DMI component* 

The AMI component is a stateless module in 
5 that it does not store nor even care about what state 

or step the application is in. What the AMI 
component does is to receive the broker module *s 
requests and fulfills those requests by interfacing 
with the application, 

10 The DMI component is essentially a 

converter — it receives data from the broker module 
and converts that data into a format suitable for 
whatever device is requesting it. Thus, if the end 
user device is a telephone 50C, then the DMI 

15 component converts the data into a Voice XML document 

and funnels it to a text-to-speech converter so that 
the data may be read to end user. Conversely, if the 
device is a WAP enabled cellphone, the data is 
converted into a WML (WAP markup language) document 

20 and transmitted to the end user cellphone. Thus, the 

data is now in a format which can be read and 
understood by the end user device. Similarly, if the 
data sent to the end user requires an input from an 
end user, the document produced by the end user 

25 device is converted to a format suitable for the 

broker module. Thus, if the device is the PSTN phone 
50C in Fig 2, the end user either speaks the required 
input or enters it through the keypad. If spoken, 
the end user's voice is converted, through a voice 

30 recognition system in the DMI component, into a Voice 

XML document. This is then converted into a format 
recognizable by the broker module. 

To manage security and user authentication, 
an authentication manager is deployed in the system, 

35 Such an authentication manager receives the user's 
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credentials such as, name, password and authenticates 
them. Once authenticated, a session manager, 
implemented within the broker module, manages that 
user's transactions. The session manager can serve a 
5 twofold duty — not only does it keep track of the 

user's actions but it would store the state that an 
application is in. Since the AMI component is 
stateless and since most applications are state 
driven, the session manager will store and monitor 

10 the application's state. Because of this, it is 

simpler for the AMI component to retrieve data from 
the application. As an example, if data A can only 
be accessed in the application by passing through 
states Al, A2, and A3, then an AMI component, not 

15 having any states, would be hard pressed to find such 

data. The AMI component may, in a single session, 
have to always go through those states just to keep 
accessing the data A. However, if the application is 
already in state A3 and the session manager has saved 

20 this state and has kept the application in this 

state, then any other time the AMI component requests 
data A, it would be ready. 

To further clarify, the broker module block 
uses the MCML language in which an MCML flow 

25 describes a set of states, to be interpreted by a 

finite state machine (FSM) . These states represent 
device-independent forms" which may contain 
^Vidgets". The DMI component or Device Adaptor (DA) 
implicitly implements the FSM and dynamically 

30 translates these states to the target devices' mark- 

up language. 

The syntax blocks representing states, 
stored in one or more MCML documents, are implemented 
using XML, and can thus be validated. An application 

35 workflow consists of one or more linked MCML 
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There are different types of MCML blocks • 
These can be : 

• Text processing block 
5 • Menu processing block 

• Getlnput processing block 

• UserDefined processing block 
Blocks can contain tags that may not be 

used by all devices* It is up to the translating 

10 process to select the tags appropriate to the target 

device. This allows the application flow writer to 
fine-tune application behaviour to suit devices with 
special capabilities. For example, some tags control 
telephony features which are not useful for HTML 

15 devices, but which may be useful for a Voice XML 

device. In that sense, some tags may be redundant in 
MCML, and would be filtered to produce the device- 
targeted documents . 

MCML documents can be produced or generated 

20 using any text editor. It is suggested that a 

validating editor or parser be used however, to 
ensure correctness. Alternately, the Saxon XML parser 
(or any other compliant XML parser) can be used to 
validate the MCML based on the DTD. 

25 Each application enabled by the multi- 

channel system requires an MCML flow, which can be 
implemented as one or more MCML documents. These 
documents should reside in a dedicated directory to 
avoid the risk of name clashes with other 

30 applications' MCML files. For example, for an expense 

reporting application, the MCML files may be called: 
.../ExpenseReporting/main.mcml 
.../ExpenseReporting/dataEntry .mcml 
..,/ExpenseReporting/ dataRetrieval .mcml 

35 The application's flow is abstracted into a 
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series of linked states, represented by MCML blocks 
within MCML documents. States consist df generic 
widgets, as detailed below* These are translated into 
the target device-specific widgets by the device 

5 adaptor, once all dynamic content, if any, has been 

inserted by embedded Java method calls. 

Placeholders for EJB (Enterprise Java Beans 
used to implement a portion of the AMI component or 
application adaptor) and local class calls can 

10 represent dynamic content. Special tags specify the 

method name and parameters required. The local or 
remote classes are then called through a 
filter/macro-processor class that returns an MCML 
block (a string) . This block replaces the place 

15 holder tag, and processing continues, with the 

eventual XSLT translation of the entire MCML document 
into the target mark-up language page, which is then 
forwarded to the client. 

In one implementation, the following 

20 guidelines, standards and subsystems were used : 

1. J2EE standard (Sun Microsystems) 
compliant application server. 

2. SAXON 5.4.1 XSLT/XML processor. 

3. Web Logic Server 5.1 provides the 

25 application server and container framework 

for all classes. The Commerce Server 
provides the Web-based Personal Interaction 
Centre (PIC is MASP's (Managed Application 
Services Platform) name for a portal) 

30 features upon which the multi-channel PIC 

(not described in this document) is based. 

4. Each application's UI flow must be 
described by a specific set of MCML 
documents . 

35 5. An XSL style sheet per channel type 
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(VoiceXML, WML, HDML, etc) is required to 
translate the MCML to the target mark-up 
language . 

6* A Device Adaptor (DA) servlet is used 
5 to dynamically generate Voice XML/WML/HTML 

or other pages using SAXON XSLT to 
translate the MCML document/ script . 
7. Error handling is done through Java's 
remote exception mechanism. AMI Components 
10 throw exceptions that are caught and 

processed by the DA, 

Ideally, the following conditions are to be 
applied in implementing the system: 

1. All EJB's and classes that generate 

15 dynamic content within the MCML flows must 

be stateless session beans that are written 
to conform to the EJB documentation for 
multi-channel access . 

2. Every request from devices must carry a 
20 session ID within URL and the current block 

name . 

3. Caching may be done by the DA to avoid 
latency in reloading and translating MCML. 
Default application flow behaviour and 

25 default block parameters can be set in a special MCML 

block. 

The following (global) properties can be 

set : 

1. Timeout in seconds for user input 
30 response. 

2. Number of prompt repetitions before 
failure. 

3. Global URL prefix. 

4. Name of starting block. 

35 5. Name of default error processing block. 
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6. Name of exit/abort block. 

7, Session timeout. 

Example: 

<! — (default settings) — > 
5 <globalproperties> 

<property name^"timeout" type="int" value="30"/> 
<property name="repeatnum" type="int" 

valuer" 3 "/> 

<property name="systemURL" type="text" 
10 value="www. nortelnetworks . com"/> 

</ globalproperties> 

MCML states can be categorized into the 
following types of blocks: 

• Text display; 
15 • Menu options; 

• Get user input; 

• User-defined (method call) . 

A complete MCML application flow must also 
include other descriptions, such as error handling, 
20 version definitions, and embedded comments. These can 

be categorized as follows: 

• Global properties; 

• Error handling block; 

• Version description; 
25 • Copyright description; 

• Default settings - it includes timeout and other 
configuration information; 

• Disconnect block - to handle hang-up events during 
telephony access, 

30 MCML inherits its syntactic constructs from 

XML. Reference to XML specification should be made 
for in-depth information on syntactic issues. The 
MCML is defined in Backus-Naur Form (BNF which is a 
generic meta-language used to describe computer 

35 language) format as follows: 
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ApplicationFlow :: = <?xml version= ^^1.0"?> 
<iacml> 

<applicationname/>application name 
5 <copyright>copyright description</copyright> 

<version>version description</version> 
(default settings) 

<globalproperties> (properties) </globalproperties> 
<errorhandle> (processing block 
10 name) </errorhandle> 

<startblock> (processing block name) </startblock> 
<endblock> (processing block name) </endblock> 
(FSMflow) 
</mcml> 
15 deafultsettings : := 

<def aultsettings> 

<timeout/> timeout 

</def aultsettings> 
20 properties : := <properties> (property) ?</properties> 

property : := 
<property> 

<name/>property name 

<type/> (int I long I double I float I string | 
25 date | time) 

<size/> size of the property 
<value/> value of the property 
<def ault/>def ault value 
</property> 
30 default definitions ::= 

<default> 

(properties) 
</default> 
FSMflow : : = 
35 <FSMFlow> 
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{processing block) * 
</FSMFlow> 


Processing block : := 
5 TextBlock I MenuBlock | GetlnputBlock 1 

UserDefinedBlock 
blockbody : := 

(Text block | Menu block I Get Input block | List 
block I UserDefined block) 

10 MCML text processing blocks allow the 

display of text* This content can be either 
dynamically generated by an EJB or class, or can be 
static. Text blocks can also define buttons, for use 
with WAP browsers* These are not used in Voice XML, 

15 The grammar is as follows: 

Text block : := 

<block blocktype="TextBlock" blockname="blockname"> 
[ (action) ] 

<properties> (property) ?</properties> 
20 <prompt> (Message) ?</prompt> 

<buttonsettings> (buttonsetting) *</buttonsettings> 
// for WAP 

(<text>(text content) </text>) * 
<nextblocks> 
25 (<hitbutton name="buttonname" 

goto="nextblockname'V>) * 
</nextblocks> 
</block> 
action : := 
30 <action> 

<method name="methodname" [type="ejb"] 
interface="interf acename" [ jndi="jdni-path"] > 
<params> 

(<param name="param-name" type=" text"/>) * 
35 </params> 
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<result name="result"/> 
</method> 
</action> 

text content :: = [$ (property name) | user-defined 
5 text] 

MCML menu blocks generate a list of choices 
on the device. When the user selects one, the FSM 
will go to the associated next state. Menu choices 

10 can cause variables to be set. These variables are 

typically used to maintain state and are managed by 
the DA/FSM. These are saved using the state manager 
to allow multiple simultaneous sessions. The menu 
items may be static or dynamically generated by 

15 embedded method calls. 

The XML description of this processing 
block is as follows: 
Menu block : 

<block blocktype="MenuBlock'' blockname="blockname"> 
20 <properties> (property) ?</properties> 

// not currently used 
<prompt> (Message) ?</prompt> 

// menu title string 
<menuitems> 

25 (<menu title="your menu name" id="your menu 

id"/>)? //the items 
< / menui t ems > 
<choices> 
(<nextblock id="your menu id" 
30 goto="nextblockname'' dtmf="digits'V> 

) ? // nextblock definitions must match 
menui t ems 

</choices> 
</block> 


35 
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The MCML Getlnput processing block is used 
to collect the input data from a user. It posts an 
input form page on the device's browser first and 
then waits for the input, 

5 The syntax description is as follows: 

Getlnput block : := 

<block blocktype="GetInputBlock" 
blockname="blockname''> 
<properties> 
10 (property) ? 

</properties> 

<prompt> (Message) ?</prompt> 

<buttonsettings> (buttonsetting) *</buttonsettings> 
// for WAP 
15 <form title="form title"> 

(f ormitem) ? 
</form> 
<nextblocks> 
<f illed>block name</f illed> 
20 <timeout>hangup block</timeout> 

<defaultblock>block name</def aultblock> // 
handle default case 

</nextblocks> 
f ormitem : : = 
25 <input name="fieldname" 

type= (password | text I numeric) 
size=the length of the field 

title-"fieldname''> 
default= the default value for this field 
30 </input> 

The UserDefined MCML processing block is a 
data processing block. It does not post any page to 
the browser at all. It serves to make method calls 
to the application adaptor EJB methods, or optionally 
to local classes. The resulting output is saved in 


35 
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FSM variables and can be used in subsequent 
processing blocks. The syntax description is as 
follows : 

UserDef inedblock : := 

5 <block blocktype=''UserDefinedBlock" 

blockname="blockname"> 
<properties> 
(property) ? 
</properties> 
10 [action] 

<nextblocks> 
<f ailure>block naine</f ailure> 
<success>block name</success> 
<defaultblock>block name</def aultblock> // 
15 handle default case 

</nextblocks> 
</block> 


Integration Details 

For each application, an MCML flow must be 
written to describe the application workflow. The 
associated EJB' s and called classes must also be 
written, and the linkage between the MCML variable 
name, state names, and class names must be done so 
that these can work in concert. This means that the 
EJB's and MCML must be written with a knowledge of 
each other. 

To test, the EJB's must be deployed on the 
application server, the MCML files stored under the 
public__html directory hierarchy, and the DA invoked 
using a client. 

The appropriate XSL style sheet can be 
passed as a request parameter to the DA, and the 
resulting target specific mark-up should be returned. 
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Return Codes and Error Handling 

EJB's or other called classes return errors 
using one of two mechanisms: 

1. Throwing a remote exception, to be 
5 caught by the DA, 

2. Returning a null string instead of 
dynamically generated MCML. 

Both are handled in the same way: 
The DA will detect the error; 

10 - if the method called was not part of an EJB, or if 

it was not an authentication exception, or if the 
retries above failed, then the DA will go to the 
failure branch in the UserDefined block that called 
the method. This should point to a block that handles 

15 the error, either by notifying the user, or 

attempting retries; 

- the DA reserves a special variable called _error 
Message that is guaranteed to always contain the 
string returned by the last exception caught. 

20 

Example Usage 

Two examples of MCML code follow: 
<?xml version^ "1.0"?> 
<!-- filename: calendar .mcml -> 
25 <! — Date: August 22, 2000 — > 

<! — The following MCML document describes a Calendar 
application workflow. 

note: It assumes authentication is 

passed. 

30 The description of workflow is as 


follows: 
(Text) 
35 application. 


1. Calendar application welcome page 
C: Welcome to the Calendar 
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goto 2 ask for date 
2. Ask for the appointment date 


(Getlnput) 


C: Please say the appointment date. 
5 goto 3 get summaries 

3. Get the summaries of the specified 
date (UserDef ined) 

Call EJB to get summaries for the 

specified day 

10 save summaries in somewhere else. 

got 4 play summaries. 

4. Say the summaries (Menu) 

repeat goto 4 

detail goto 5 ask for the 

15 specified time 

other day goto 2 ask for date 

5. Ask for time (Getlnput) 
goto 6 to get the detail 

6. Get the detail (UserDef ined) 

20 Call EJBs to get the detail and save it 

somewhere else. 

goto 7 to play the detail. 


7. Play the detail (Menu) 
25 repeat goto 7 

other appointment goto 5 ask for time 
other day goto 2 ask for date 

— > 

<mcml > 

30 <applicationname>Calendar</applicationname> 
<copyright>Nortel Networks Copyright, July, 
2 000</copyright> 

<version>MCML Version 1 , 0</version> 
< ! — (default- settings) — > 

35 <globalproperties> 
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<property name=" timeout" type="int" 

value="30"/> 

<property naine="repeatnum" type="int" 

value="3"/> 

5 <property name="systemURL" type="text" 

value=" www . nortelnetworks . com" /> 

<property name="userid" type="text"/> 
<property name="password" 
type="pas sword" /> 
10 </ globalpropertles> 

<errorhandle> 

<hangup blockname="hangupblock"/> 
<error blockname="errorblock"/> 
</ errorhandle> 
15 <FSMFlow> 

<block blocktype="TextBlock" 
blockname=" start "> 

<! — ask for date — > 
<text> Welcome to the Calendar 
20 application. </text> 

<nextblocks def aultblock="askf ordate"> 
<timeout goto="disconnect"/> 
</nextblocks> 
</block> 

25 <block blocktype="GetInputBlock" 

blockname="askfordate"> 

<! — ask for date — > 
<prompt> 

<message msgmode="Voice XML" 
30 msgtype="text" content="Please say the appointment 

date."/> 

</prompt> 
<form> 

<input name="date" type="date" 

35 title="date"/> 
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</form> 

<nextblocks defaultblock="getsuinmaries"> 
<! — demo goto hangup — > 
<filled goto="getsui!maries"> 
5 <Gutput naine="date" type="date"/> 

</filled> 
</nextblocks> 
</block> 

<! — need a specific implementation using 
10 servlet or java class — > 

<block blocktype="UserDef inedBlock" 
blockname="getsummaries"> 

<properties/> 
<action> 

15 <! — method name="getSummaries" 

interf ace="com.nortel .masp .mca.MCML.CalendarWrapper" 
source="http://localhost:7001" — > 

<! — method name="makeEJBcall" 
interf ace="com,nortel .masp,mca,MCML.CalendarWrapper" 
20 source="http: //localhost : 7001" — > 

<! — method name="getSummaries" 

type="ejb" 

interf ace="com.nortel .masp.mca . MyC a lendar Remote" 
e j bhome= " com ♦ nor t el . masp * mca .My Calendar Home " 
25 jndi="mca .MyCalendarHome" 

ejbhost="t3 : //localhost : 7001" — > 

<method name="getSummaries" type="ejb" 
interf ace=" com. nort el .masp .mca,MyCalendarRemote" 
j nd i = " mc a • MyC a 1 enda r Home " > 
30 <params> 

< ! — param 

name= " r emo t e=com . nor te 1 , masp . mca . CalendarRemot e " 
type="text"/— > 

< ! — param 

35 name=" jndi=mca*CalendarHome" type="text"/ — > 


10 


15 
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<param 

naine="CalendarURL=http : //wleey006 . ca • nortel . com" 
type="text"/> 

<param name="port=81" type="text"/> 

^ <param name="username=demo" 

type="text"/> 

<paraia name="password=new2day" 

type="text"/> 

<param name="date" type="text"/> 
</params> 

<result name="summariesiuenu"/> 
</method> 
</action> 
<nextblocks> 

<success goto="saysummaries"/> 
<f ailure goto="noappointment "/> 
</nextblocks> 
</block> 

<block blocktype="MenuBlock" 
b 1 o c kn ame= "says uitmia r i e s " > 

{$suinmariesmenu} 
</block> 

<block blocktype="TextBlock" 
blockname="noappointment"> 
25 <properties/> 

<prompt/> 
<buttonsettings> 

<button buttontype="accept" 

label="back"/> 

<button/> 
</buttonsettings> 

<text>No appointment for this day</text> 
<nextblocks def aultblock="askf ordate"> 
<hitbutton name="back" 
35 goto="askfordate"/> 


20 
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</nextblocks> 
</block> 

<I — it needs a specific servlet or class 
to implement this block — > 
5 <block blocktype="UserDeflnedBlock" 

blockname= " getdet ai 1 " > 

<properties/> 
<action> 

<method name="getDetail" type="ejb" 
10 interf ace="com,nortel ,masp,mca.MyCalendarRemote" 

j ndi="mca • MyCal endarHome " > 

<params> 

<param name="UID" type="text"/> 
<param name="port=81" type="text"/> 
15 <param name="username=demo" 


type="text"/> 
type="text"/> 


<param name="password=nGw2day" 


</params> 

20 <result name="detail"/> 

</method> 
</action> 

<output><property name= "detail" 
type="text"/></output> 
25 <nextblocks> 

<success goto="saydetail"/> 

<failure goto="saynoappointment"/> 
</nextblocks> 
</block> 

30 <block blocktype="MenuBlock" 

blockname="saydetail"> 

<properties/> 
<prompt> 

<message msgtype="text" content="your 
35 appointment is as follows: "/> 


13499ROUS01U 25 

<message insgtype="text" 
content="{$detail}"/> 

<message iasgmode="Voice XML" 
msgtype="text" content=" Please choose one of the 
5 following options: summary, another day, or 

repeat . "/> 

</prompt> 
<menuitems> 

<menu title="repeat" id="repeat"/> 
^^^e"^" title="back to summary" 
id=" summary" /> 

<menu title="another day" id="another 

day"/> 

< /menu it ems > 

<choices defaultblock="askfortime"> 
<nextblock id="repeat" 
goto="saydetail"/> 

<nextblock id="summary" 
goto="saysummaries"/> 

20 

<nextblock id="another day" 
goto="askfordate"/> 

</ choices> 
</block> 

<block blocktype="TextBlock" 
25 t)lockname="saynoappointment"> 

<! — ask for date — > 
<action> 

<method name="toSpeakableDate" 

interface="com.nortel,masp.mca.MCML.MCMLutils"> 

^ <parains> 

<parain name="date" type="text"/> 
</parains> 

<result name="speakableDate"/> 
</method> 
'^^ </action> 
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<prompt> 

<message insgtype="text" content="No 
appointment on {$speakableDate } "/> 
5 </prompt> 

<nextblocks def aultblock="askfortime"> 
<tiiaeout go to=" hangup" /> 
</nextblocks> 
</block> 

10 <block blocktype="TextBlock" 

blocknaine="hangup"> 

<buttonsettings> 

<button buttontype="accept" 

label-"OK"/> 
15 <button/> 

</buttonsettings> 

<text>Thank you for calling calendar 
application* Goodbye • </text> 

<nextblocks defaultblock== "disconnect "> 
20 <hitbutton name="OK" 

go t o= " as kf ordate " / > 

</nextblocks> 
</block> 

<block blocktype="DisconnectBlock" 
25 b 1 o c kn aine= " di s conne c t " > 

<disconnect/> 
</block> 
</FSMFlow> 
</mcml> 

30 
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<?xml version= "1.0"?> 
<!— filename: IMAP4.mcml — > 
<!— Author: T. Barake — > 
5 <!— Date: Sept 12, 2000 — > 

<!— The following MCML document describes a 
Messenger application workflow. 

note: It assumes authentication has 
occurred and stored in session manager 
10 Workflow states: 

MAIN 
Email main menu 

1- Get list of unread mail headers 

goto UNREAD 

2- Choose a mailbox 


15 


20 


30 


SETBOX 
CONTACTS 


25 messages 


- goto 
3- Contact list 

- goto 


EXITtoIMAP 
UNREAD 

Menu of unread headers if any 
otherwise 
Display a message saying no unread 


35 


uses : 

SELECT MAIN 
SELECT 

Display the detail 
uses : 

UNREAD MAIN 
SETBOX 

Menu of available mailboxes is 

displayed 

SELECTBOX MAIN 
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10 


15 


20 


25 


30 


— > 

<m.cinl> 


SELECTBOX 

Menu of unread headers if any 
otherwise 

Display a message saying no messages 
uses : 

DETAIL MAIN 
DETAIL 

Display the detail 
uses : 

SELECTBOX MAIN 
CONTACTS 

Menu of contact headers if any 
otherwise 

Display a message saying no contacts 
uses : 

SELECTCONTACT MAIN 
SELECTCONTACT 

Display the detail on a contact 
uses : 

CONTACTS MAIN 


35 


<applicationname>Calendar</applicationname> 
<copyright>Nortel Networks Copyright. October, 
20C0</copyright> 

<author>A. Barake</author> 
<version>MCML Version 1 . 0</version> 
<! — (default settings) — > 
<globalproperties> 

<property name=" timeout" type="int" 

value="30"/> 

<property name="repeatnum" type="int" 

value="3"/> 

<property name="systemURL" type="text" 
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value="www . nortelnetworks . com"/> 

<property name="userid" type="text"/> 
<property name="password" 
type="password"/> 
5 </globalproperties> 
<errorhandle> 

<hangup blocknaine="hangupblock"/> 
<error blocknanie="errorblock"/> 
</errorhandle> 
10 <FSMFlow> 

<block blocktype=="MenuBlock" 
blockname="start"> 
<properties/> 
<pronipt> 

15 <message msgtype="text" 

content="Messenger eMail"/> 

</prompt> 
<menuiteius> 

<iaenu title="l. Get unread mail headers" 


20 id="l" /> 

/> 


<iaenu title-"2. Choose a mailbox" id-"2" 


<menu title="3. Contact list" id="3" /> 
</raenuitems> 

25 <choices def aultblock="get" dtmf="truG"> 

<nextblock id="l" 
goto-" FETCHUNREADHEADERS" /> 

<nextblock id="2" goto="SETBOX"/> 
<nextblock id="3" go to= "CONTACTS" /> 

30 </choices> 


<! — button required EXITtoIMAP — > 
</block> 


35 


<block blocktype="UserDef inedBlock" 
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blockname=" FETCHUNREADHEADERS " > 

<properties/> 
<action> 

<niethod name="getUnreadMessageHeaders" 

5 type="ejb" 

interface="com.nortel .masp.mca. Iitiap4Remote" 
jndi=="raca . Iraap4Home"> 

<params> 

<param name="mailbox=inbox" 
10 type==" text"/> <! — (j ava . lang. String mailbox) — > 

</parains> 

<result name="unreadheadersirienu"/> 
</method> 
</action> 
15 <nGxtblocks> 

< succe s s go to= " DI S PUNREADHEADERS " / > 
<failure goto="NOMESSAGES"/> 
</nextblocks> 
</block> 

20 <block blocktype="MenuBlock" 

b 1 0 C kn ame= " D I S PUNREADHEADERS " > 
{ $unreadheadersmenu } 
<nextblocks def aultblock="MAIN"> 
<hitbutton name="OK" 
25 go to= " DI S PDETAI LS " / > 

<hitbutton name="back" goto="MAIN'V> 
</nextblocks> 
</block> 

<block blocktype="TextBlock" 
30 blockname="NOMESSAGES"> 

<properties/> 
<prompt/> 
<buttonsettings> 

<button buttontype="accept" 

35 label="back"/> 
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<button/> 
</buttonsettings> 

<text>No unread messages found</text> 
<nextblocks def aultblock="MAIN"> 
5 <hitbutton name="back" goto="MAIN"/> 

</nextblocks> 
</block> ( 
<block blocktype="UserDefinedBlock" 
bloc kname= " S E TBOX " > 
10 <properties/> 

<action> 

<method naTae="getFolderNaines" type="ejb" 
interf ace="com*nortel .masp .mca . Imap 4 Remote" 
jndi="mca . Iinap4Hoine"> 
15 <result naine="foldernainesiaenu"/> 

</inethod> 
</action> 
<nextblocks> 

<succGSS goto=="DISPFOLDERS"/> 
20 <failure goto="NOFOLDERS"/> 

</nextblocks> 
</block> 

<block blocktype="MenuBlock" 
blockname="DISPFOLDERS"> 
25 <! — selecting a folder here 

sends you to the header list fetch for that folder 
> 

<! — must return variable called 
foldername with correct folder in it — > 
30 { $ f o 1 de r name sme nu } 

<nextblocks defaultblock="MAIN"> 
<hitbutton name="OK" 
goto=" FETCHHEADERS " /> 

<hitbutton name="back" goto="MAIN"/> 
35 </nextblocks> 
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</block> 

<block blocktype="UserDef inecLBlock" 
blocknaine=" FETCHHEADERS " > 
<properties/> 
5 <action> 

<iaethod naitie= " ge tAllMe s sageHeader s " 

type="ejb" 

interface="coia.nortel .masp.mca. Iinap4Remote" 
jndi="iaca. Iinap4Home"> 
10 <params> 

<paraiti naine=" { $inailbox} " 
type="text"/> <! — ( java. lang^String mailbox) — > 

</params> 

<result name="allheadersraenu"/> 
15 </inethod> 

</action.> 
<nextblocks> 

<success goto="DISPHEADERS"/> 
<failure goto="NOMESSAGES"/> 
20 </nextblocks> 

</block> 

<block blocktype-"MenuBlock" 
blockname="DISPHEADERS "> 

<! — selecting a folder here 
25 sends you to the header list fetch for that folder — 

> 

<! — must return variable called 
foldername with correct folder in it — > 

{ $allheadersmenu} 
30 <nextblocks def aultblock="MAIN"> 

<hitbutton name-"OK" 
go to- " DI S PDETAI LS " / > 

<hitbutton name="back" goto="MAIN"/> 
</nextblocks> 
35 </block> 
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<block blocktype="UserDef inedBlock" 
blockname=="DISPDETAILS"> 
<properties/> 
<action> 

5 <method naiae="getSelectedMessage" 

type="ejb" 

interf ace="coiu,nortel •masp.inca. Imap4Remote" 
jndi="mca, Imap4Home "> 

<params> 

10 <parain name=" {$xaailbox} " 

type="text"/> <I — ( java. lang. String mailbox, int 
mail^Id) — > 

<param name=" {$itiail_Id} " 

type="int"/> 
15 </params> 

<result naine="messagedetails"/> 
</iuethod> 
</action> 
<nextblocks> 

20 <success goto="SHOWDETAILS"/> 

<failure goto="NOMESSAGES"/> 
</nextblocks> 
</block> 

<block blocktype="TextBlock" 
25 blockname="SHOWDETAILS"> 

{ $messagedetails} 
<nextblocks def aultblock-"MAIN"> 

<hitbutton naine="OK" goto="KAIN"/> 
</nextblocks> 
30 </block> 

<block blocktype="TextBlock" 
blockname= " done " > 

<buttonsettings> 

<button buttontype="accept" 

35 label="OK"/> 
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<button/> 
</buttonsettings> 

<text>Thank you for calling the Messenger 
application . Goodbye • </text> 
5 <nextblocks defaultblock="disconnect"> 

<hitbutton name="OK" 

goto-"askfordate'7> 

</nextblocks> 
</block> 

10 <block blocktype="Di5ConnectBlock" 

blockname="disconnect"> 

<disconnect/> 
</block> 
</FSMFlow> 
15 </mcinl> 

Regarding the authentication manager, 
the authentication subsystem consists of the front- 
line authentication servlet, an LDAP directory shared 
with MASP, and application-specific authentication 
20 methods, implemented as part of the application 

adaptors' EJB, As noted above, the term application 
adaptor is interchangeably used to refer to the AMI 
component . 

The role of the authentication servlet is 
25 to assign a session to the new user, and to maintain 

and manage this session for authenticated users in 
conjuction with the Device Adaptor (DA) • It assigns a 
temporary session key during login and a session key 
after validation, and dispatches the request to the 
30 DA. The dispatched request is modified to suit the 

client browser's protocol and mark-up language, so 
that the DA can reply appropriately. 

A valid login will result in a session 
key being assigned and the storing of the user's 
35 login and password infoiination in the session 
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manager, for access by the application adaptors. 

The authentication servlet ' is responsible 
for timing out an inactive session as well as logging 
all login attempts made to it. 

5 The authentication servlet uses an SQL 

table to store and maintain an authenticated user 
session, and all information that is necessary to 
continuing that session. Session information specific 
to the display of pages, or the flow of control are 

10 stored in the Multi-Channel session manager in the 

DA, 

Since application adaptor EJB's are 
designed to be stateless, they store all session 
state variables in the session manager. In the case 

15 of the authentication method within an EJB, its role 

is to create and store a client object to be used by 
the application access methods. 

The role of the authentication method 
associated with the application adaptor EJB' s is to 

20 create a session between the application adaptor and 

the back-end application, using the login credentials 
supplied to the DA and stored in the session manager 
by the authentication servlet. All application 
adaptor EJB methods assume that a valid client 

25 connection exists in the session. If this assumption 

is not true, the session manager throws an exception, 
which is caught by the DA. The DA will then call the 
EJB's authentication method to create the missing 
client connection, and will retry the call. This is 

30 possible since EJB's are stateless. 

By using this approach, EJB methods can 
be coded in a straightforward manner, and 
authentication is handled transparently to most of 
the code. There must, however, be a login method 

35 associated with each EJB, responsible to do the login 
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negotiation in response to the authentication 
exception. Such methods are potentially re-usable by 
multiple EJB's that access similar back-end protocols 
(for example IMAP4) . 
5 The following example only covers 

authentication examples for the following protocols: 
HTTP, IMAP, LDAP. Further authentication code will 
have to be written along the same lines to enable 
single sign-on capability in applications that use 

10 protocols other than these. 

The system is accessed through a single 
URL, which points to the authentication servlet. This 
servlet is responsible for dispatching the request in 
a manner appropriate for the requesting client 

15 browser (ex: WML, HTML, HDML, Voice XML) . 

Ideally, the system would use the 
following requirements : 

- Each application adaptor EJB requires a 
special authentication method called 

20 login"; 

- Application adaptor EJB methods must 
assiame that the client connection to the 
application is stored in the session 
manager using a special name; and 

25 - The special name for the authentication 

exception substring must be defined in the 
^'util . constants" object. 
Normal communications between the 
application adaptor EJBs and their applications need 
30 an authenticated session. Whether or not this 

session has been initiated will be checked 
transparently (as the EJB tries to read the 
application client from the Session Manager) . If the 
client session cannot be found in the session 
35 manager, an exception will be thrown, which will 
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prompt the device adaptor to call the special login 
EJB method to set up this session. 

The following design guidelines and tools 
may be used: 

5 1. Java (Sun's JDK 1.2.2) is used for 

authentication EJB coding. 

2. The J2EE 2.0 specification for EJB 
interface and deployment is adhered to. 

3. The application adaptor EJB' s are 

10 stateless, in that any device-side method 

call can be made at any time. State is 
maintained outside the EJB's, in the unique 
Session Manager. Therefore EJB's can be 
replicated and clustered. 

15 4. Getting an authenticated session open 

to an application must be transparent and 
be able to re-login to the application if 
the previous application session has timed 
out . 

20 5. We want to keep the authentication 

mechanism in the application adaptor EJB as 
simple as possible. 

5. Authentication credentials and session 
dispatching occurs transparently to the DA 
25 and application adaptors, and is handled by 

the exposed authentication servlet. 
Ideally, the following conditions will also 

apply: 

1. All EJB's must use the session manager 
30 to store state or instance information. No 

instance variables are allowed. The EJB' s 
should be clusterable across different 
servers and operate with a single logical 
session manager. 
35 2. Since the client objects stored in the 
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Session Manager may contain socket handles 
or files handles (and those handles are not 
transferable between machines), the device 
adaptor must always make calls to EJBs on 
5 one server only. 

Each application adaptor EJB will have a 
standard method call named ^^login" which will be used 
by the device adaptor to set up an authenticated 
session with the application. This method will take 
10 the standard parameters for all application adaptor 

EJBs: A session manager, and a property list which 
potentially contains additional parameters (if 
required) . 

That session will be read back from the 

15 session manager by each EJB method and used to 

coinmunicate with the application. If the session is 
created successfully by the login method, it stores 
it in the session manager using a key name with the 
following format: 

20 <application name><loginClientSubstring> 

The ^^loginClientSubstring" is retrieved from the 
util . constants class. 

This allows the other EJB methods to 
retrieve the client connection with the application 

25 using a standardized name, and also allows the DA to 

identify the exception that may be thrown if this key 
does not exist (no login has yet occurred) . The DA 
does this by parsing for the substring on all 
received exceptions, and it treats this particular 

30 exception as a special case. 

The following is a description of the steps 
taken by the authentication servlet when handling a 
request : 

♦ If incoming http request contains a system 
35 authentication key, check the key (see method below) . 
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If valid, pass the request on to the DA. 
♦ If there is no key associated with the 'request, or 
if the key is invalid (it may have expired or may be 
an attack), challenge the user agent (client browser) 
5 as follows: 

• Save the incoming URL based on the 
generated key; 

• Generate a temporary key for this reply 
and forward with device-specific form to 

10 the user; 

• Call the dispatch method (see key 
generation description below) , to 
generate a device-specific login form by 
sending a request to the DA to translate 

15 login, mcml; 

• The dispatch method determines the type 
of client (WML, Voice XML, HDML, or 
HTML) . The default type is HTML 
(settable) ; 

20 • Record the WebLogicSession key returned 

from the DA; 

• Wait for reply. When received, check 
the validity of the temp key (see 
algorithm below) ; 

25 • Convert user id and password from 

numeric if required (for Voice XML) 

• Lookup the user id/password in the LDAP 

• If authentication succeeds, proceed 
below, otherwise, retry above 

30 • Restore the original URL 

• Delete temporary login key 

• Create a authentication session key 
(see key generation description below) 
and append to request 

35 • Replace authentication key with 


13499ROUS01U 40 

WebLogicSession key returned from the 
login step 

• Add the user id and password to the 
request sent to the DA 
5 ♦ Forward the request to the DA 

Two types of keys are possible — temporary and 
session key with the same contents otherwise. 
The steps in the key generation process may be as 
10 follows : 

• Encode an expiry date (set to 1 hour for session 
keys, shorter for temp keys, but configurable) 

• Encode a random number 

• Encode sender's IP (IPV4 or IPV6) 

15 • RSA sign a buffer containing the above 4 items. 

• Add the signature to the end of the key buffer 

• Base64 encode the buffer 

To validate the key, the process may take the 
following steps : 
20 • decode the key using Base64 decoding 

• Split the result into key and signature 

• Verify the key using the RSA signature. 

• Check key's age - if near expiry {within 10 
minutes) and it is a session key, reset the expiry 

25 to another hour since this request counts as activity 

• Check that the sender's IP still matches that of the 
sender when the key was created. 

• Base further processing on the key type 

EJB login methods are required to connect 
30 to the back-end applications. The following is a 

template for such methods. 
EJB_wrapper (...) { 
try { 

AppEJB .method ( SessMgr, parameterl , 
35 parameter2...) ; 


10 


15 
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} 

catch InvalidXXX { 

AppEJB. login ( SessMgr ); 

} 

5 } 

AppEJB { 

public methodl ( SessMgr, ... ) { 

client = SessMgr.getCurrentStateO .get ( 
"AppCLIENT" ) ; 

} 

public method2 ( SessMgr, ... ) { 

client = SessMgr.getCurrentStateO .get { 
"AppCLIENT" ) / 

} 

public login ( SessMgr ) { 

AuthEJB. login ( SessMgr, "AppCLIENT" ); 

} 

20 } 

AuthEJB { 

public login ( SessMgr, String app ) { 
// Get userid/password 

String userid = 

25 SessMgr.getCurrentStateO • get ("userid") ; 

String passwd = 

SessMgr.getCurrentStateO . get ("password") / 

// Connect to LDAP DB with userid/password (if 
necessary) 

// Lookup login credentials for user to login to 

app 

/ / Login to app 

ClientClass client = new ClientClass (userid, 
password) ; 

/ / Store client in sessMgr 


30 


35 


I 
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SessMgr .getCurrentState () .put ( app, client 

); 

} 
} 

5 Concerning the session manager, the multi- 

channel architecture requires a session manager to 
maintain user and application session ^tate and to 
provide dynamic state storage and retrieval services 
to the application adaptors. Since the application 

10 adaptors may be distributed over several servers, 

this service must be unique or replica-aware, and 
must serve all adaptors from the same central session 
repository. It may of course be implemented as 
distributed objects drawing from the same database. 

15 The actual mechanism and location of the session 

repository is transparent to application programmers 
(device adaptors and EJBs.) The session manager 
object is passed by reference to all adaptors and 
EJBs. The session manager implicitly maintains a 

20 session ID. The session ID is embedded in the URL of 

all transactions with the client, since cookie 
support cannot be assumed. 

The session manager provides the following 
advantages : 

25 1 . Provides user authentication into the 

application. The application adaptors can use the 
session manager to access applications. 

2. Dynamic session instance management 
that includes application specific instance fields 

30 (containers) , for example ^^session-id'' or 

^^phoneNumber" . The session manager is used to store 
such dynamic session state information on behalf of 
the application and device adaptors. 

3. User profile management. The multi- 
35 channel session manager maintains the end-user 
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specific configuration (profile) which includes a 
list of provisioned applications with associated 
devices supported (properties) . Profiles are created 
and populated via the Management Interaction Center 
5 (MIC) and Business Interaction Center (BIC) interface 

in the completed system. MIC is a portal for the 
hosted application provider (HSP) to provision 
businesses to use MASP applications. BIC is the 
hosted business portal, used to manage their 

10 employees' access to hosted applications. The 

information is stored using Web Logic's 
Personalization Server facilities, but would be 
manually populated for the interim release 
checkpoints and for testing purposes. Web-based 

15 provisioning is assumed to be as provided by MASP 

1.1. Examples of configuration fields on a per-user 
basis would consist of: 

a) Predefined (by user) e-mail responses 

b) Predefined (by user) appointment 
20 siimmaries and locations 

c) List of enabled applications, and URI's 
on a per-channel basis 

d) APM related configuration information 

e) PIC preferences 

25 f) Application specific generic workflows 

(MCML) for multi-channel enabled 
applications, and for the PIC. 
g) Application specific time-out 
overrides . 

30 h) Sign-on enabling information (APM 

codes) , 

i)User preferences (for the PIC) such as 
application menu order, 

internationalization settings, ASR/TTS 
35 engine preferences. 
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The session manager may require the following : 

1. Location and linkage information for 
Personalization Server (or other) database. 

2. APM related interface information 
5 (server URI) . 

3. Resource file locations 

4. Session ID base 

5. Log file URI 

6. Default system time-out values 

10 

The following functions are available to the users of 
the session manager: 

1. Session creation, which returns a unique • 

session state object. 
15 2. Session retrieval via session manager. 

3. Put data into session - add an item to 
the session' s property list, name-value 
pair, where value is an object. 

4. Get data from a session - name-value pair 
20 property list. 

5. Delete a value from a session. 

6. Save a session state once the state has 
reached a new, consistent stage. 

7. Destroy the current session, i.e., 
25 logout . 


Internal methods: 

1. Update of profile information ~ retrieval 
from personalization server. 
30 2. Log-in to a given application (may use 

APM) . 

3. Log-out from a given application. 

4. Get a new unique session id. 


35 


The session manager has to implement the 
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functionality described above by providing the 
following services: 

1. Create a unique user session upon single sign-on 
from PIC. 

5 2. Creation of a session, and retrieval of user 

profile data from personalization server database 
based on user credentials. 

3. Association with a session-id, suited for 
passing, as post data over http to the devices and 

10 adaptors (must fit within thin client browser data 

size constraints) . 

4. Read-write access to session information via 
session id* This includes user profile, and dynamic 
session data. 

15 5. Destruction of user session, through API call, or 

as a result of inactivity timeout. 


The session manager also manages the following data: 

1. Persistent user profile information: provisioned 
20 applications and associated devices supported, 

application specific generic workflows (MCML) , sign- 
on enabling information (APM codes) , PIC related 
preferences . 

2. Non-persistent application session state and 
25 instance information. This data is application 

dependent and non-static. The EJB's that make up the 
application adaptors can use the session manager to 
store state and session information as required. This 
data is subject to inactivity timeout constraints. 

30 

The following design guidelines can apply: 
1. The session manager is necessarily a high-demand 
service^ and requires an efficient implementation, 
which would include caching, passivation and 
35 clustering support. 


''I 
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2. Java (Sun's JDK 1,2.2) is used for device and 
application adaptor coding, - 

3. WebLogic Server 5.1 provides the application 
server and container framework for these classes. 

5 Weblogic Server's in-memory replication of 

HttpSession will be used to increase the throughput 
of session management, JDBC-based session management 
can also be considered in the future. The actual 
choice (in-memory replication vs JDBC) is transparent 

10 to the application layer (device adaptors and EJBs,) 

The Personalization Server (v 2.0) provides the Web- 
based PIC features upon which the multi-channel PIC 
(not described in this document) is based. 

The session manager is ideally able to 

15 handle a large number of sessions concurrently, and 

must therefore use an efficient mechanism for data 
storage and retrieval. The limitations on performance 
are to be load tested and must concord with MASP 
specifications for number of concurrent multi-channel 

20 users. 

The DMI component or device adaptor (DA) 
can be implemented using the example provided below. 

It should be noted that the example 
provided uses a PSTN telephone as the end user 
25 device. 

It should also be noted that the ASR/TTS 
(text-to-speech) channel functionality is dependent 
on the VoiceXML implementation. 

Furthermore, since the voice channel has inherent 
30 limitations from a user-interface point of view, 

i.e. : 

a) one-at-a-time menu selection capability, 
.b) limited data entry capability, 

c) limited (to approximately 100 words) vocabulary 
35 for acceptable speaker-independent recognition. 
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The user interface for this implementation 
has some inherent problems. The user interacts with 
the system using DTMF tones and speech. Typically, 
the system prompts the user with generated and pre- 

5 recorded text and sounds, and the user can respond 

with DTMF keystrokes or with spoken commands. The 
interface is analogous interactive voice response 
(IVR) call flows, but the menus may be made ''flatter'' 
to take advantage of the larger response range of ASR 

10 as opposed to DTMF. 

Some responses and prompts are standard for all 
applications, akin to the "^0" or ^^#" DTMF 

request in an IVR system: 
General guidelines ; 

15 a. The user can say, '"help" or ''I don't understand", 

or ""^repeat" to obtain more information or an 
alternate prompt. 

b. Numeric responses can be entered via DTMF or ASR. 
Yes and No responses can be entered via DTMF as 1 or 

20 2 respectively. 

c. The user can say '"hang-up" to exit the 
application at any time. 

d. Passwords and PIN' s should only be entered via 
DTMF to avoid being overheard or misinterpreted. 

25 

System requests: 

a) The system prompts the user with sounds, pre- 
recorded text/ or TTS generated text, as indicated in 
the MCML flow. 

30 b) Failure to respond within a timeout setting in 

the session manager will result in the prompt be 
rephrased, and if no response is received after a 
longer timeout, the application will disconnect. 

The multi-channel session manager maintains 

35 the end-user specific configuration. This 
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configuration information is used by the device 
adaptor to determine which applications are enabled 
for a particular user and channel* 

Access to this information is through the 
5 session manager interface described elsewhere* 

A single device adaptor is required for the 
ASR/TTS channel. Its role is to translate the MCML 
application flow into a state machine instance to 
drive the client, 
10 The device adaptor is called from the PIC 

application when the user selects an application from 
the main menu. 

The DMI component executes the following 
steps when accessing an application : 
15 a) Start a selected application session, given the 

application name, and the APM key obtained from the 
PIC s login. The following steps are then taken: 

- Logs-in to the selected application 

- If successful, this effectively starts a session 

20 for the user by calling the session manager to set-up 

an instance for the application session 

- Obtain the application's EJB coordinates for the 
application from the session manager 

- Obtains the MCML document from the session manager. 
25 - Translates the first state to a device specific 

template using the XSLT service and the device- 
specific style sheet. 

- Translate placeholders for dynamic content by 
making EJB calls. 

30 - Drive the application interaction including state 

transitions using EJB calls until the user exits the 
flow or a timeout occurs 

- Returns a status code to the calling application 
(PIC) , 

35 a) Force an instance of a session to exit, based on 
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its session ID. Clean up any instance data in the 
session manager. 

The design of the ASR/TTS component of the 
multi-channel subsystem involves two major sub- 
5 components : 

a) The application adaptor, which consists of a set 
of Stateless Session Beans that communicate with the 
applications • The adaptor also consists of a MCML 
(XML multi-channel application flow) document that 

10 specifies the Finite State Machine (FSM) states that 

the adaptors require to implement the functionality 
specified. 

b) The device adaptor, which drives the ASR/TTS 
engine VoiceXML implementation, in an application 

15 independent way. 

Both these adaptors make use of 
underlying infrastructure services. These include the 
session manager, XSLT and XML related classes, and 
the application server's container framework classes, 

20 The following design guidelines were used 

in this specific Implementation : 

1. Java (Sun's JDK 1.2.2) is used for device and 
application adaptor coding. Java extensions not in 

25 the standard distribution are based on the jars 

delivered with Web Logic. 

2. Web Logic Server 5.1 provides the application 
server and framework for these classes (typically 
servlets) - The Personalization Server (v 2.0) 

30 provides the Web-based PIC features upon which the 

multi-channel PIC (not described in this document) is 
based. 

3. The device adaptors are application independent. 
The same device adaptor should work transparently 

35 with multiple applications. They implement specific 
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instances of the state machine described in the 
application-specific MCML documentation i Dynamic 
content generation links are contained in the MCML. 
It should be noted that the device adaptor is 
5 application independent. No assumptions about how the 

application flow can be made within that subsystem. 
This must be tested with different EJB's and MCML 
flows - 

Furthermore/ it should be clear that the 
10 MCML flows are necessarily device independent, in 

that they cannot depend on a client having certain 
capabilities beyond a common set of lowest common 
denominator controls, such as: 

Menus / selection lists; 
15 Accept and back buttons; 

Data entry fields, numeric, 
alphanumeric, and password; and 

Labels and prompts . 
As mentioned above, the DA (device 
20 adaptor or DMI component) is implemented as a 

servlet and the AA' s (application adaptors or AMI 
components) are implemented as EJB's, All calls (with 
an exception described below) are therefore remote 
object calls, and can return remote exceptions, 
25 The DA can also call local utility 

classes either to facilitate application adaptation, 
or to allow more MCML functionality. 

The DA is responsible for generating 
calls to AA methods under the guidance of the MCML 
30 script currently running. Since the calls to the AA' s 

are generated dynamically, the called method 
signatures must be standardized. Additionally, the 
exception handling must be standardized to allow the 
DA to respond to business, system, and authentication 
35 errors. 
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The DA responds to exceptions in two distinct ways: 
l.It catches non-authentication exceptions, and 
allows the MCML to take the failure branch in the 
script - potentially allowing another MCML block to 

5 handle the error appropriately. 

1 .Authentication exceptions cause the DA to call the 
AA's authentication methods, which is responsible for 
obtaining a user session with the application using 
the credentials stored in the session manager by the 

10 authentication servlet. There is a limit to the 

number of iterations the DA will try on a given auth- 
exception to avoid looping forever. Authentication 
exceptions are identified based on the returned 
string signature, which must contain a unique sub- 

15 string. 

As an example of a DA servlet, the 
following source code implements a servlet which 
transforms an MCL document into VoiceXML. 


20 /* 

*@version 1.0 

*/ 

package com.nortel .masp.mca. servlet; 

import java.io.*; 

25 import javax. servlet 

import javax. servlet .http.*; 

import java.util.*; 

import com. icl.s axon.*; 

import com. icl.saxon. output.*; 

30 import com. icl . saxon. expr . * ; 

import org.xml. sax.*; 

import com.nortel .masp.mca.MCML.*; 

import com.nortel .masp.mca. stateManagement , * 

import com.nortel .masp.mca.util .* ; 
35 /** 
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* VoiceServlet- Transforms a supplied MCML document 
into VoiceXML 

* using the supplied stylesheet xmlServlet .xsl 
*/ 

public class VoiceServlet extends HttpServlet { 

private static final String MCML_VTABLE - 
"ma spMu 1 1 i Ch ann e 1 Ac cessSessi onMCMLVT ACBLE " ; 

private static final String 
DEFAULT__LOGIN_METHOD_NAME_KEY = "loginMethodName" ; 

private static final String 
DEFAULT_INDEX_MCML_KEY =" de fault IndexMCML" ; 

static private final String 
DEFAULT_ERROR_HANDLING_MCML_KEY = 
"def aultErrorHandlingMCML" ; 

static private final int debug = 1; 
static private final int testVersion = 0/ 
static private final String INVALID__USERjy[CML = 
McaProperties . get Ins tance ( ) . getProperty ( "da . def aul t In 
validUserMCML", "mca/invaliduser ,mcml" ) ; 

static private final String ERROR__HANDLING_MCML = 
McaProperties . get Instance ( ) . getProperty ( "da • def aultEr 
rorHandlingMCML" , "mca/errorhandler • mcml " ) ; 

static private final String INDEX_MCML = 
McaProperties . getlnstance ( ) , getProperty ( "da . def aultin 
dexMCML", "mca/pic.mcml") ; 

static private final String LOGIN_METHOD_NAME = 
McaProperties . getlnstance ( ) . getProperty ( "da , def aultLo 
ginMethodName", "login") ; 

static private final String START_BLOCK__NAME = 
"start"; 

static private final String BLOCK_NAME = "__b"; 
static private final String XML_SOURCE = "_x"; 

static private final String XSL_STYLE = "_1"; 
static private final int MAX COUNT = 3; 
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static private final String CONTENT__TYPE = 
"content- type" ; 

static private final String MCA_HEADER = 
"racaheader" ; 

5 

static private final String XSL__EXT =".xsl"; 
static private final String XML_EXT =".iacml"; 
static private final String DEFAULT_APP__PATH = 
McaProperties • get Instance ( ) . getProperty ( "da . def aultMC 
10 MLAppPath", "mca/") ; 

* doGetO - accept request and produce 
response<BR> 

* URL parameters: <UL> 

15 * <li>__x - URL of source document</li> 

* <li>_l - URL of stylesheet</li> 

* <li>clear-stylesheet-cache - if set to yes, 
empties the cache before running* 

* <li>URL format: 
20 /demo?uniqueID?__x=xxx •mcml?__l=xxx ,xsl?_b=start 

* </UL> 

* gparam req The HTTP request 

* @param res The HTTP response 

25 public void doGet (HttpServletRequest req, 

HttpServletResponse res) 

throws ServletException, lOException 
{ 

doPost{req, res); 

30 } 

* doPostO - accept request and produce 
response<BR> 

* URL parameters: <UL> 

35 * <li> x - URL of source document</li> 
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* <li>_l - URL of stylesheet</li> 

* <li>clear-stylesheet-cache - if set to yes 
empties the cache before running. 

* </UL> 

5 * @param req The HTTP request 


* Sparam res The HTTP response 
*/ 

public void doPost (HttpServletRequest req, 
10 HttpServletResponse res) 

throws ServletException, lOException 

{ 

Log. log (Log. DEBUGGING, this . getClass ( ) , 
PrintUtil.convertToString(req) ) ; 
15 String source = null; 

/*req.getParameter (XML_SOURCE) 

String style = null; 
/*req. getParameter {XSL__STYLE) ; */ 

String blockname = null; 
20 /*req,getParameter (BLOCK__NAME) ;*/ 

String querystr - req. getQueryString ( ) ; 
SessionStateManagerDef manager = 

SessionStateManagerAbstractFactory.makeManager (re 
res) ; 

25 SessionState state = null; 

SessionState tmpState = new 
SessionState ("tmpawewe2 33 6623233") ; 

boolean bInvalidUser = false; 

// Chech if the session is created or not 
30 if ( !manager.isSessionStarted() ) 

{ // Create a new session and initializ 

it. 

initSession (manager) ; 

} 

35 state = manager. getCurrentState 0 ; 
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if (state == null) 
{ 

Log. log (Log. ERROR, getClass(), "state 

== null") ; 

5 bInvalidUser = true; 

state = tmpState; 

} 

SessionState varTable = 
10 getVarTable (state) ; 

String sessionKey = state . getSessionKey () ; 
Log .log (Log. DEBUGGING, getClass () , 
"SessionKey = " + sessionKey) ; 

Log. log (Log. DEBUGGING, getClass () , 
15 "QueryString: : " + querystr) ; 

String cururlO; 
String absURL = 
req.getParameter {"absoluteURL") ; 

String hostURL = req. getScheme ( ) + "://" + 
20 req. gets erverName 0 + ":" 

+ req.getServerPort {) + 

req.getServletPath 0 ; 

if (absURL != null absURL. equals ("1") ) 
{ 

cururlO = hostURL; 

} 

else 
{ 

cururlO = req. getServletPath () ; 
30 } 

cururlO = manager .encodeURL (cururlO) ; 
hostURL = manager. encodeURL (hostURL) ; 
Log. log (Log, DEBUGGING, getClass () , 

"######## New version Servlet My Current URL2 - " 

35 + cururlO) ; 
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String id = 


56 

null; // temporary id for test 


ParameterSet params = new ParameterSet ( ) ; 
5 // Check if there is a in cururlO 

params • put ( " id" , new 
StringValue (generateld ( ) ) ) ; 

varTable.put ("url", hostURL) ; 
ServletOutputStream out = 
10 res . getOutputStream { ) ; 

Enumeration p = req.getPararaeterNaiaes ( ) ; 
while (p.hasMoreElements () ) 
{ 

String name = (String) p. nextElement () ; 
15 String value = req. getParameter (name) ; 

if {name. equals {XML__SOURCE) ) 
{ 

source = value; 
String tmp = null; 
20 try 

{ 

tmp = 

(String) varTable. get (XML__SOURCE) ; 

} 

25 catch (Exception e) 

{ 

tmp = null; 

} 

if (tmp 1== null) 
30 { 

if 

(source. equals ( (String) varTable. get (XML_SOURCE) ) ) 

continue; 

} 

35 } 
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else if (name • equals (XSL^STYLE) ) 
{ 

style = value; 
String tmp = null; 
5 try 

{ 

tmp = 

(String) varTable.get (XSL_STYLE) ; 

10 } 

catch (Exception e) 

{ 

tmp = null; 

} 

15 if (tmp != null) 

{ 

if 

(style. equals { (String) varTable.get (XSL_STYLE) ) ) 

continue; 

20 } 

} 

else if (name. equals (BLOCK_NAME) ) 
{ 

blockname = value; 
25 //do not put the blockname into 

parameterset until we start XSLT 

continue; 

} 

else if 

30 (name. equals ( "clear-stylesheet-cache" ) ) 

{ 

if (value. equals ("yes") ) 
clearCache ( ) ; 

} 

35 if (value != null) 
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{ 

pararas .put (name •intern "() , new 
StringValue (value) ) ; 

Log. log (Log. DEBUGGING, getClass () , name 
5 + + value) ; 

varTable .put (name, value) ; 

} 

else 

10 Log. log (Log. DEBUGGING, getClassO, name 

+ " does not have its value."); 
} 

if (blockname == null && source == null) 
source INDEX_MCML; 
15 if (source == null) 

{ 

try 
{ 

source = 

20 (String) varTable. get (XML_SOURCE) ; 

} catch (Exception e) 
{ 

source = INDEX__MCML; 

} 

25 params .put (XML_SOURCE, new 

StringValue (source) ) ; 

varTable. put (XML_SOURCE, source) ; 

} 

if (style == null) 
30 { 

try 
{ 

style = 

(String) varTable, get (XSL_STYLE) ; 
35 } 
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catch (Exception e) 
{ ^ 
// temporarily code 

####################### 
5 style = "html"; 

Log^log (Log. DEBUGGING, 
getClass 0 , "XSL style sheet is not found. Using 
html.xsl as default!"); 
10 } 

params ,put (XSL_STYLE, new 
StringValue (style) ) ; 

variable, put (XSL^STYLE, style) ; 

} 

15 if (blockname == null) 

{ 

blockname = START_BLOCK_NAME; 
//source = INDEX_MCML; 
//variable. put (XML_SOURCE, source) 
20 Log. log (Log, DEBUGGING, getClass () , 

"blockname == null, use start as block-name"); 

//params .put (BLOCK_NAME, new 
StringValue (START_BLOCK__NAME) ) ; 
} 

25 if (style. indexOf ("vxml") >= 0) 

cururlO = hostURL; 
if (cururlO.indexOf ("?") < 0) 

cururlO = cururlO + "?__dmy=l"; 
Log. log (Log. DEBUGGING, getClass () , 

========================\n" + cururlO 

35 params. put ("cururlO", new 
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StringValue (cururlO) ) ; 

int innerCount = 0; 
int outCount =0; 
do 

5 { 


outCount ++; 
bInvalidUser = false; 
try 

10 { 

// Run the MCML filter to get the 
specified MCML block according to the given block 
name 

String mcmlText = null; 
15 do 

{ 

innerCount ++; 
bInvalidUser = false; 
logMsg ("source =" + source); 
20 logMsg("_b + blockname) ; 

String path; 

if ( source •indexOf (".racial") >= 0) 
path = 

getServletContext ( ) . getRealPath (DEFAULT__APP_PATH + 
25 source) ; 

else 

path = 

getServletContext 0 . getRealPath (DEFAULT__APP_PATH + 
source + XML_EXT) ; 
30 MCMLFilter mcmlFilter = new 

MCMLFilter (path, blockname, manager); //variable); 

try 
{ 

mcmlText = mcmlFilter . run () 

35 } 
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catch (InvalidUserException e) 
{ 

Log • log (Log . ERROR, 

getClass ( ) , e) ; 
5 // Invalid user 

bInvalidUser = true; 
source = INVALID_USER_MCML; 
blockname = 

10 START_BLOCK__NAME ; 

} 

catch (NoBlockException e) 
{ 


15 getClass () , e) ; 


ERROR HANDLING MCML; 


Log* log (Log. ERROR, 

bInvalidUser = true; 
source = 

blockname = 


20 START_BLOCK_NAME; 

} 

catch (UserDefinedBlockException e) 

{ 

String gotoStr = 
25 e . toString ( ) , substring (e . toString ( ) . indexOf ( " : " ) + 

1) . trimO ; 

System,out.println("######################userDefined 
Block 

handling##########################^f###^f#|^|f^^^^^^^^^^^ 

30 #########") ; 

System. out. println(gotoStr) ; 
System.out.println{"####################|^###^^|f#^lf^^^ 

###########################################n) . 

StringTokenizer gotoParams = 
35 new StringTokenizer (gotoStr, "&"); 
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params . clear ( ) ; 

params . put ( " curur 1 0 " , new 

StringValue (cururlO) ) ; 

params .put ("id", new 
5 StringValue (generateld { ) ) ) ; 


10 


15 


20 


25 


String prevSource = source; 
String prevBlockname = 

blockname; 

while 

(gotoParams .hasMoreTokens () ) 

{ 

StringTokenizer 

oneParaxnToken = new 

StringTokenizer (gotoParams • nextToken ( ) , ) ; 

String name ~ 

oneParamToken • nextToken ( ) ; 

string value = null; 
if 

(oneParamToken, hasMoreTokens () ) 


oneParamToken • nextToken () ; 


(name . equals (XML SOURCE) ) 


{ 


} 

if 


value = 


30 


value; 
null; 


35 (String) varTable. get (XML__SOURCE) ; 


source = 


String tmp = 


try 
{ 


tmp = 
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catch (Exception re) 


10 


15 


25 


30 


35 


null; 


tmp 


} 

if (tmp • 


null) 


{ 

if 

(source. equals ( (String) variable . get (XML_SOURCE) ) ) 
continue; 

} 

} 

else if 

(name. equals (XSL_STYLE) ) 


20 value; 


null; 


(String) variable. get {XSL_STYLE) ; 
catch (Exception re) 


null; 


null) 


style = 

String tmp = 

try 
{ 

tmp 

} 
{ 

tmp 

} 

if (tmp != 
{ 
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if 

(style. equals { (String) variable. get (XSL_STYLE) ) ) 
continue; 

} 


20 


else if 

(name . equals (BLOCK_NAME) ) 

{ 

10 

blockname = 

value; 

// do not put 
the blockname into parameterset until we start XSLT 

innerCount = 

15 0; 

blnvalidUser 

- - true; 

continue; 

} 

variable. put (name, 
value) ; 

params.put(naine.intern(), new StringValue (value) ) ; 

} 

if (! blnvalidUser || 
25 (PJ^evBlockname. equals (blockname) && 

prevSource. equals (source) ) ) 

throw new Exception (); 

} 

catch (Exception e) 
{ 

Log. log (Log -ERROR, 

getClassO, e) ; 

blnvalidUser = true; 
source = 

35 ERROR_HANDLING MCML; 


30 
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blockname = 

S TART_BLOCK_NAME ; 

} 


MAX COUNT) ; 


} while (bInvalidUser && innerCount < 


10 


15 


25 


30 


35 


if (innerCount >= MAX_COUNT) 
{ 


innerCount = 0; 

throw new Exception ("Block (" + 
blockname + ") is not found in " + source); 

} 

params .put (BLOCK_NAME, new 
StringValue (blockname) ) ; 

varTable.put(BLOCK_NAME, blockname); 
apply (style, mcmlText, params, req, 

res, state) ; 
20 } 

catch (Exception e) 
{ 

variable .put ( "_errorString" , 

e.toStringO ) ; 

Log. log (Log. ERROR, getClass(), e) ; 
if 

(source. indexOf (ERROR_HANDLING_MCML) >= 0) 

bInvalidUser = false; 

else 
{ 

bInvalidUser = true; 
source = ERROR_HflNDLING_MCML; 
blockname = START_BLOCK_NAME; 
params. clear 0 ; 
params. put ("cururlO", new 
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StringValue(cururlO) ) ; 

params .put {"id", new 
StringValue (generateldO ) ) ; 

params .put (XML_SOURCE, new 

5 StringValue (source) ) ; 

params. put (XSL__STYLE, new 

StringValue (style) ) ; 

//params .put (BLOCK__NAME, new 
10 StringValue (blockname) ) ; 

} 

} 

//params = createNewParams (blockname) ; 
} while (bInvalidUser && outCount < 
15 MAX_COUNT) ; 

manager. saveState () ; 

} 

private void initSession( SessionStateManagerDef 
manager) 
20 { 

manager . startSession ( ) ; 
SessionState state = 
manager .getCurrentState () ; 
state -put (DEFAULT_LOGIN_METHOD_NAME_KEY, 
25 LOGIN_METHOD__NAME) ; 

state. put (DEFAULT_INDEX__MCML_KEY, 

INDEX_MCML) ; 

state .put ( 
DEFAULT__ERROR_HANDLING__MCML_KEY, 
30 ERROR_HMTDLING_MCML) ; 

} 

* getServletInfo<BR> 

* Required by Servlet interface 
35 */ 
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public String getServletlnfo {) { 

return "Calls SAXON to apply a s-tylesheet to 
a source document"; 
} 

5 /** 


* Apply stylesheet to source document 


10 


private void apply (string style. String source, 

ParameterSet params, 
HttpServletRequest req, 
HttpServletResponse res, 
SessionState varTable) 
throws SAXException, j ava . io . lOException 

15 { 

ServletOutputStream out = 
res . getOutputStream ( ) ; 

if (style==null) 
{ 

out. print In ("No style parameter 

supplied") ; 

return; 

} 

if {source==null) 
25 { 

out.println("No source parameter 

supplied") ; 

return; 

} 

30 try 

{ 

StringWriter strout = new 

StringWriter 0 ; 

PrintWriter pout = new 
35 PrintWriter (strout) ; 
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try 
{ 

String contentType = 
(String) varTable . get (CONTENT^TYPE) ; 

5 

String mcaHeaderFileName = 
(String) varTable. get (MCA_HEADER) ; 

String lacaFilePath = 
getServletContext 0 . getRealPath (DEFAULT_APP__path + 
10 mcaHeaderFileName) ; 

FileReader in = null; 
try 

{ 

in = new 

15 FileReader (mcaFilePath) ; 

} . 

catch (FileNotFoundException 
{ 

varTable. put ("_errorString", e.toStringO ) / 

throw e; 

} 

Buf feredReader bufin = new 

Buf f eredReader (in) ; 

// Read the header 
25 String rdln; 

while ( (rdln = 
buf In.readLine 0 ) !== null) 

{ 

pout. println (rdln) ; 

30 } 

// set content type 
res. setContentType (contentType) ; 

} 

catch (Exception e) 
{ // If there is no content-type 


35 
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passed from sessionState, we hardcode it here. 

///////////////////////////////////////r///////////// 
/////////////////////////////////////// 

Log. log (Log •DEBUGGING/ getClass () , 
5 "^#|f##^# content-type and mcaheader from auth 

servlet are not correctly" ) ; 

if (style. indexOf ("vxml") >- 0) 
{ 

10 pout .println ( "<?xml 

version=\"1.0\"?>") ; 

res . setContentType ( "text/vxml" ) ; 
//setContentType ("text/vnd.wap.wml") ; 

15 } 

else if (style, indexOf ("wml") >= 0) 

{ // for wml 

pout .println ( "<?xml 

version-\"1.0\"?>") ; 
20 pout.println("<IDOCTYPE wml 

PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\" 

\"http: //www -wapforum.org/DTD/wml_l . 1 .xml\">") ; 

res . setContentType (" text /vnd.wap. wml") ; 

//setContentType ("text/vnd.wap.wml") ;*/ 
25 /^setContentType (details .getMediaType () ) ; 

} 

else if ( style. indexOf ("hdml") >= 0) 
{ // for hdml 

pout .println ( "<?xml 

30 version=\"l-0\"?>") ; 

pout.println("<»DOCTYPE wml 
PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\" 
\"http: //www. wapforum.org/DTD/wml__l , 1 .xml\">") ; 
res . setContentType ( "text/x-wap.wml" ) ; 
35 //setContentType ("text/vnd.wap.wml") ; 
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setContentType (details • getMediaType ( ) ) ; 

} 

else 
{ 

5 res -setContentType ("text/html") ; 

//setContentType ("text/vnd.wap*wial") ; 
setContentType (details , getMediaType { ) ) ; 

} 

10 

///////////////////////////////////////////////////// 
/////////////////////////////////////// 

} 

PreparedStyleSheet pss = 
15 tryCache (style) ; 

StyleSheetlnstance ssi = 
pss •makeStyleSheetlnstance ( ) ; 

OutputDetails details = 
pss . getOutputDetails ( ) ; 


20 details . setWriter (pout); 

ssi*setOutputDetails (details) ; 
ssi • setParams (params) ; 
Log. log (Log. DEBUGGING, getClass () , 
"The input MCML as follows\n" + 
25 " ==:==================MCML 

BEGINNING=================\n" + 

source + "\n" + 

30 ) ; 

StringReader sourceReader = new 


StringReader (source) ; 

ssi .transform (new 
ExtendedlnputSource (sourceReader) ) ; 
35 String xmlstr; 
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xmlstr = strout .toStringO ; 

pout .close 0 ; 

sourceReader • close ( ) ; 

Log* log (Log, DEBUGGING, getClass () , 

5 

"========The result 

after XSLT ==:===-=:=\n" 


10 


+ xmlstr 

"\n======-==-==END===============" ) ; 

PostProcess postProc = new 
PostProcess (req, res, variable) ; 

try 

15 { 

postProc. run (xmlstr) ; 

} 

catch (ServletException err) 
{ 

20 res.getOutputStreamO .println ( "Error MethodProcess : 

+ err, getMessage ( ) ) ; 

} 

} 

catch (SAXException err) 
25 { 

throw err; 
//out. println (err. getMessage () ) ; 
} 

} 

30 // first get unique ID from URL 

// if there is no id=XX, it means this 
request is from a new session 

// if there is an id, then try to llok up 
MCMLVariables table, if the 

// table is not found. The request is 


35 
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treated as a new request. 

public SessionState getVarTable (SessionState 
5 state) 
{ 

if (testVersion == 0) 
return state; 

10 else 

return gMCMLtable; 

} 

* Maintain prepared stylesheets in memory for 
15 reuse 
V 

private synchronized PreparedStyleSheet 
tryCache (String url) throws SAXException { 
String path; 
20 if (url.indexOf {".xsl") >= 0) 

path = 

getServletContext 0 • getRealPath (DEFAULT_APP_PATH + 
url) ; 

else 

25 path - 

getServletContext ( ) , get Real Path {DEFAULT_APP_PATH + 
url -f XSL_EXT) ; 

if (path==null) 
{ 

30 throw new SAXException ( "Stylesheet " + 

path + " not found" ) ; 
} 

PreparedStyleSheet x = 
(PreparedStyleSheet) cache •get (path) ; 
35 if (x==null) 
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{ 

X = new PreparedStyleSheet ( )'*; 
X* prepare (new ExtendedlnputSource (new 
File (path) ) ) ; 
5 cache. put (path, x) ; 

} 

return x; 


} 

10 private void logMsg (String loglnfo) 

{ 

Log. log (Log. DEBUGGING, getClass {) , 

loglnfo) ; 

} 

15 private synchronized String generateldO 

{ 

Date tm = new Date ( ) ; 

Long In = new Long (trci. getTime () ) ; 

return In.toStringO ; 

20 } 
/ + * 

* Clear the cache. Useful if stylesheets have 
been modified, or simply if space is 

* running low. We let the garbage collector do 
25 the work. 

*/ 

private synchronized void clearCache () 
{ 

cache = new HashtableO; 

30 } 

private static SessionState gMCMLtable = new 
SessionState ("12345676878999") ; 

private Hashtable cache = new HashtableO; 


35 


} 
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To create proper EJB's which can be called 
from a DA, the following guidelines apply : 
1) All EJB methods must have the following signature: 
String EJBMethodName (SessionStateManagerDef 
5 manager. Properties params) 

throws CreateException, RemoteException, 
RemoveException 

Error handling: 

10 The Device Adaptor uses two ways to check whether the 

EJB call fails: 

Catch an exception from the EJB method 
Check if the return value is null 


15 Parameter passing: 

The method should get its associated 
parameters from the params Properties according to 
its corresponding parameter name. An alternate 
mechanism for data passing between method calls is to 

20 use the SessionStateManager to store state data 

between calls. 

The following example illustrates the latter for 
getting a username and password: 

SessionState state; 
25 state = manager .getCurrentState () ; 

String username = (String) state. get ("username") ; 

String password = (String) state -get ("password") ; 

2) Each application EJB must implement an 
30 authentication method. The signature is as follows: 


String login (SessionStateManagerDef manager. 
Properties params) 

throws CreateException, RemoteException, 
35 RemoveException 
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This method is be called by the DA if the 
EJB method fail to find an active session in the 
Session State, as a result of the session manager 
throwing an exception which is passed up to the DA. 

5 

3) The proper MCML Syntax for making EJB or Class 
method call must be followed. 

The following MCML block gives an example of a call 
to the getSummaries in CalendarEJB 
10 <block blocktype="UserDefinedBlock" 

blockname="getsummaries"> 

<properties/> 

<action> 

<method name="getSummaries" type="ejb" 
15 inter face=" com. nortel .masp.mca.CalendarRemote" 

j ndi= "mca . Cal endarHome " > <params > 
<param 

name="applicationURL=http : //wleeyOO 6 , ca . Nortel . com" 
type="text"/> 

20 <param name="port=81" 

type="text"/> 

<param name="date" type=" text "/> 

</params> 

<result name="summariesmenu"/> 
25 </method> 

</action> 
<nextblocks> 

<success goto="saysummaries"/> 
<f allure goto="noappointment"/> 
30 </nextblocks> 

</block> 

The ^'interface" attribute in the method element 
specifies the remote interface of an EJB. The "jndi" 
attribute specifies the JNDI_NAME for the EJB. 
35 To create classes which are callable from the DA 
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through the MCML scripts (or broker modules), the 
following guidelines apply : - 

The DA may be used to invoke non-EJB 
classes, that can serve to enhance its functionality. 
5 These classes are called under the control of an MCML 

script, in the same way as an AA is called. 
These classes must follow the rules below: 

1) The methods must handle all the exception 
internally. The DA does NOT catch any exceptions 

10 thrown. 

2) The methods only have one input parameter - 
Properties params. 

All the parameter the method needs have 
to get from the passed properities. 
15 For example: toSpeakableDate { ) is in the 

com, Nortel. masp.mca. MCML. MCMLutils class and is 
defined as follows: 

public String toSpeakableDate (Properties params) 
{ 

20 String theDateStr = params . getProperty ("Mate") ; 

String theReturnStr = null; 
* « 

return theReturnStr; 

} 

25 The associated MCML required is as follows: 

<block blocktype="MenuBlock" 
bloc kname= " ve r i f yda t e " > 

<action> 
<method name="toSpeakableDate" 
30 interf ace="com.nortel .masp.mca.MCML,MCMLutils"> 

<params> 

<param name="date" type=" text"/> 
</params> 

<result name="speakableDate"/> 
35 </method> 
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</action> 

<prompt> 

<message insgtYpe="text" content="Your 
entered date is { $speakableDate} . "/> 
5 <raessage msgtype="text" content="If it is correct, 

please say yes, otherwise say no."/> 
</prompt> 
<menuit€ms> 

<menu title="yes" id="yes"/> 
10 <menu title="no" id="no"/> 

< /menu it ems > 
<choices> 

<nextblock id="yes" 
goto="getsummaries"/> 
15 <nextblock id="no" 

goto="askf ordate"/> 

</choices> 
</block> 

An example of a simple MCML workflow that includes 
20 an EJB call action is provided below : { test.mcml) 

<?xml version= "1,0"?> 
<mcml> 

<FSMFlow> 

<block blocktype="UserDef inedBlock" 
25 blockname=" start "> 

<action> 

<method name="getSummaries" type="ejb" 
interf ace="com.nortel .masp .mca .MyCalendarRemote" 
jndi="mca •MyCalendarHome"> 
30 <params> 
< ! — param 

name=" r emo te=com . nor t el , masp . mca . CalendarRemote " 
type="text"/-"> 

< ! — param 

35 name=" jndi=mca .CalendarHome" type="text"/ --> 
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<param 

name="CalendarURL=http : //wleeyOO 6 . ca . nor t el . com" 
type="text"/> 

<param name="port=81" 


type="text"/> 
type="text"/> 


<param name="username=demo" 
<param name="password=new2day" 


type="text"/> 

10 <param name="date" type="text"/> 

</params> 

<result name="suinmariesiaenu"/> 
</method> 
</action> 
15 <nextblocks> 

<success goto="saysuininaries"/> 
<failure goto="saynoappointment"/> 
</nextblocks> 
</block> 

20 <block blocktype=="DisconnectBlock" 

blockname="disconnect"> 
<dis connect /> 
</block> 
</FSMFlow> 
25 </iacial> 

Regarding the application adaptor or the 
AMI component, an example is provided which utilizes 
the Calendar, E-mail and Contact List as the 
application. 

These applications may have the following 
capabilities : 


30 


35 


Calendar Express: 

•get appointment summaries for a given date 
incrementally (limited by client^ s buffer size) 
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-get details (location, start, end, summary, text) 
for a given appointment based on start time 
- set an appointment for a given date and time using 
standard locations and summaries 

5 

E-mail : 

a) indicate how many unread messages you have 

b) set current mailbox 

•get summary lines (headers) and message ids for 
10 unread or for all messages in a mailbox incrementally 

(limited by client's buffer size) 

d) get message text based on message id or next 
message in a mailbox or next unread message 

e) delete the current message (akin to voice mail 
15 deletes on the current message) 

f ) send standard reply to a message based on message 

id 

Contact list: 

20 get contact list incrementally (limited by client's 

buffer size) 

•get detail information for a given contact name 

• send a standard message to a person in the contact 
list 

25 • prepare a receiver list for an e-mail based on the 

contact list 

• add the sender's name to the contact list based on a 
received e-mail id number 

This example assumes that the application 
30 session is available to the adaptor through a session 

id mechanism described elsewhere. Also, the example 
assumes the following : 

Populating fields in the session manager's 
database does the application and user provisioning. 
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•The standards based API's used here to interface 
with the email application (SMTP and IMAP4) 

•No special client software is assumed (or indeed 
possible in most cases) on the target. Since some 
5 channels may have inherent limitations from a user- 

interface point of view, i.e.: 

a) one-at-a-time menu selection capability^r 

b) data entry capability is limited (to 
approximately 100 words) vocabulary for 

10 acceptable speaker-independent recognition 

The session manager described above has, 
relative to the application adaptor, the following 
functions : 

1. Maintains the end-user specific 
15 configuration. 

2. User authentication into the 
application. Using a session id, the 
application adaptors can use the session 
manager to access applications, using 

20 existing sub-systems like APM. 

3. Dynamic session instance management. The 
session manager can be used to store 
dynamic session state information on behalf 
of the application adaptor. The ^^handle" 

25 into that state information is the session 

id, obtained through the PIC. 

4. User profile management. Profiles are 
created and populated via the MIC and BIC 
interface in the completed system, but 

30 would be manually populated for the interim 

release checkpoints, and for testing 
purposes. Web-based provisioning is assumed 
to be as provided by MASP 1.1. Examples of 
configuration fields on a per-user basis 

35 would consist of: 
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81 


10 


a) Predefined (by user) e-mail responses; 

b) Predefined (by user) appoiAtment 
summaries and locations; 

c) List of enabled applications, and URI's 
on a per-channel basis; 

d) Time-out values for application access; 

e) Application specific instance fields 
(containers) . For example ^^session-id" . 

To access the applications, the application 
adaptors must accomplish the following : 
Application : Calendar: 


Functions 


15 


20 


Application 
Functions: 


25 


30 


a) Get appointment summaries (headers) 
based on session id and date 

b) Get appointment detail, based on 
session id, appointment date and time 

c) Set an appointment, based on 
session id, appointment date and time, 
and input appointment data fields 

e-mail 

a) Set a mailbox to be current based 
on session id, and mailbox id 

b) Get the number of unread messages 
in all mailboxes, or in the specified 
mailbox, based on session id and 
mailbox name. 

c) Get message summaries, based on 
session id, mailbox name. Get 
summaries for all messages (unless 
unread-only flag is set) . Provision to 
do this incrementally is provided to 
account for device buffer limitations. 


35 Application : Contact List: 
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Functions : 


10 


a) Get names in contact list 
incrementally based on session id, and 
number of entries (limited by client*^ s 
buffer size) 

c) Get detail on a given name, based 
on session id and contact name 

d) add a name to the contact list 
based session id and contact name 


As noted above, the application adaptor 
consists of a set of Stateless Session Beans that 
communicate with the applications. The broker module 
consists of a MCML (XML multi-channel application 

15 flow) document that specifies the Finite State 

Machine (FSM) states that the application adaptors- 
require to implement the functionality specified. 

The device adaptors use the application 
adaptors to present device-specific drives the ASR- 

20 TTS engine (VoicePortal) , in an application 

independent way. 

The application adaptors described here are 
implemented as Stateless Session Enterprise Java 
Beans deployed within a Java-based application 

25 server, and communicate with the target applications 

on the ^"back-end". The EJB's abstract the application 
interface presented to the device adaptors and are 
written once per application such that different 
device adaptors without modification may use them, 

30 The user' s flow through the application is 

guided by the broker module which is an MCML (multi- 
channel mark-up language) XML document that contains 
references to the EJB's. It is the MCML document 
that guides the device adaptor in its sequence of 

35 calls to the EJB's, which are effectively action 
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methods used to generate dynamic content for the 
application flow^ 

In this example, the following design 
guidelines were applied : 
5 1. Java (Sun's JDK 1.2.2) is used for 

device and application adaptor coding. 

2. The J2EE 2,0 specification for EJB 
interface and deployment is adhered to, 

3. Web Logic Server 5.1 provides the 

10 application server and container framework 

for these classes. The Personalization 
Server (v 2.0) provides the Web-based PIC 
(Personal Interaction Portal) features upon 
which the multi-channel PIC is based. 

15 4. The application adaptor EJB's are 

stateless, in that any device-side method 
call can be made at any time. State is 
maintained outside the EJB's, in the unique 
Session Manager. Therefore EJB's can be 

20 replicated and clustered. 

5. The device adaptors are application 
independent. The same device adaptor should 
work transparently with multiple 
applications. They implement specific 

25 instances of the state machine described in 

the application-specific MCML document - 
see below. 

6. The application's workflow is contained 
within the MCML document that can be 

30 obtained by calling the application's EJB. 

This flow describes a set of states and 
associated controls and actions that the 
device adaptor can choose to implement. 

7. All EJB's must use the session manager 
35 to store state or instance information. No 
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instance variables are allowed. The EJB's 
should be clusterable across different 
servers and operate with a single logical 
session manager. 
5 The following code is that of a Java bean 

for the calendar application 


* CalendarBean — implement the methods in this 
10 interface as well as providing 

* the implementation of the business methods, 
*@ 

*@version 1.0 
V 

15 package com,nortel .masp .mca • ejb; 

import javax.ejb.*; 

import j ava . rmi . Remote; 

import java.rmi .RemoteException; 

import j avax . naming . Ini tialContext ; 
20 import j avax. naming. NamingExcept ion; 

import java.io.*; 

import java.util . * ; 

import j ava . text . * ; 

import java.net .URL; 

25 import com.nortel .masp.mca.stateManagement . *; 

import com.nortel .masp .mca . util . *; 

import com.nortel. masp. mca. MCML.XMLTranslater; 
//import org.xml . sax. *; 
//import org.xml . sax. helpers . * ; 
30 public class MyCalendarBean implements SessionBean{ 

static private String SESSIONID = 
"CalendarSessionUserlDCLIENT"; 

static private String CONNECTURLSTR = 
"CalendarSessionConnectionURLStringCLIENT" ; 
35 static private String CALENDARID = 
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"CalendarUserlDCLIENT" ; 

static private String USERNAME 
Constants .MCAJJSERID_KEY; 

static private String PASSWORD = 
5 Constants .MCA_PASSWORD_KEY; 

static private String APPURL = 
Constants .MCML APPURL TAG; 


static private String PORT = "port"; 
10 static private String DATE = "date"; 

static private String EVENTID = "event id"; 
static private String [] months tr= { "January" 
" February" , "March" , " Apr i 1 " , "May" , " June " , " July" , 
"August" , "September" , 
15 "October" , "November" , "December" } ; 

static private int m_GMT_offset = -5; // 
Eastern time of Canada 

private SessionContext ctx = null; 
private String userSessionId = null; 
20 private boolean loginSucceed; 

private boolean logoutSucceed; 
private String url; 
private String port; 
private String curDate; 
25 private String calendarld; 

private boolean bhasEvent; 
public void ejbActivate ( ) { 

log ("CalendarBean activated") ; 

} 

30 public void ejbRemove{){ 

log ("CalendarBean Removed"); 
// logout of Calendar 

} 

public void ejbPassivate { ) { 
35 log ( "CalendarBean Passivate"); 
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} 

/** 

* Sets the session context. 

5 * Sparam SessionContext 

*/ 

public void setSessionContext (SessionContext 
context) { 

10 log ("CalendarBean Context set"); 

ctx = context; 

} 

public void ejbCreateO throws CreateException { 
} 

15 public String 

getSummaries (SessionStateManagerDef manager. 
Properties params) 
{ 

log("####################getSuinmaries() Inside 
20 EJB#################") ; 

SessionState state = 
manager . getCurrentState ( ) ; 

String theDate = 
params . get Property (DATE) ; 
25 Calendar localTime = 

Calendar . getlnstance (TimeZone . getDef ault {) ) ; 

Integer year, month, day; 
int curYear = 

localTime. get (Calendar .YEAR) ; // because the default 
30 year from V^ML is 2001 

year = new Integer (curYear ) ; 
///Integer ( theDate . substring (0, 4) ) ; 

month = new Integer ( 
theDate. substring (4, 6) ) ; 
35 day = new Integer ( 
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theDate . substring (6, 8 ) ) ; 

// System.out .print ("year = ") ; 

// System, out. print ("month = "); 

// System.out .print ("day = "); 

5 userSessionId = 

(String) state. get (SESSIONID) ; 

log(SESSIONID + "=" + userSessionId) 
url = 

(String) state. get (CONNECTURLSTR) ; 

10 

bhasEvent = falser- 
String retStr = 
getSummaries ( year . intValue ( ) , month . intValue ( ) , 
day . intValue ( ) ) ; 
15 log ("Result:") ; 

log (retStr) ; 
if ( IbhasEvent) 

retStr = null; 
if (retStr != null) 
20 { 

XMLTranslater translator = 

new XMLTranslater {) ; 

try 
{ 

25 retStr = 

translator. translate (retStr, "calsummary .xsl" ) ; 

log ( "MCML output : " ) ; 
log (retStr) ; 

} 

^0 catch (Exception e) 

{ 

retStr = null; 

e .printStackTrace ( ) ; 

} 

35 } 
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log("####################End of 
getSummariesO Inside EJB###############'##") ; 

return retStr; 

} 

5 public String getDetail (SessionStateManagerDef 

manager. Properties params) 

{ 

//log ( "####################getDetail ( ) Inside 
EJB#################") ; 

10 

SessionState state = 
manager .getCurrentState ( ) ; 

String theDate = 
params .getProperty (DATE) ; 
15 userSessionId = 

(String) state. get (SESSIONID) ; 

//log(SESSIONID + 4- 

userSessionld) ; 

url = 

20 (String) state . get (CONNECTURLSTR) ; 

String eventid = 
(String) params . get ( "UID" ) ; 

calendarld = 
(String) state, get (CALENDARID) ; 
25 log ("UID = " + eventid); 

bhasEvent = false; 
String retStr = 
getEvent (userSessionId, eventid) ; 

log ("Result: ") ; 
30 log (retStr) ; 

if (! bhasEvent) 

retStr = null; 
if (retStr != null) 
{ 

35 XMLTranslater translator = 
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new XMLTranslater ( ) ; 

try 
{ 

retStr - 

5 translator* translate (retStr, "caldetail .xsl") ; 

log("MCML output:") 
log (retStr) ; 

} 

catch (Exception e) 

10 

{ 

retStr = null; 

e . printStackTrace { ) 

} 

15 } 

log{"####################End of 
getDetailO Inside E JB#################" ) ; 

return retStr; 

} 

20 public boolean login (SessionStateManagerDef 

manager. Properties params) 
{ 

SessionState state = 
manager • getCurrentState ( ) ; 
25 String username = 

params .getProperty (USERNAt^E) ; 

if (username === null) 
username = 
(String) state. get (USERNAME) ; 
30 String password = 

params. getProperty (PASSWORD) ; 

if (password ==== null) 
password = 
(String) state. get (PASSWORD) ; 
35 String port = 
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params •getProperty (PORT) ; 

String appURL = null; 

try 

{ 

5 appURL = 

(String) state* get (APPURL) ; 

logC'appUrl = " + appURL); 

} 

catch (Exception e) 
10 { 

□ appURL = null; 

S } 

if (appURL == null) 
I J 15 appURL 

=params.getProperty (APPURL) ; 

log("appUrl = " + appURL); 
URL myUrl = null; 
try 

20 { 

myUrl = new URL (appURL); 

} 

//catch (MalformedURLException e) 
catch (Exception e) 
25 { 

e .printStackTrace ( ) ; 
return false; 

} 

port = toString(myUrl.getPort 0 ) ; 
30 appURL = myUrl.getProtocol 0 + "://" 

+ myUrl . getHost ( ) ; 

boolean bRet = login (appURL, port, 
username, password) ; 

if (bRet) 

35 { 
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state •put (SESSIONID, 

userSessionId) ; 

state .put (CONNECTURLSTR, 

url) ; 

5 state .put (CALENDARID, 

calendarld) ; 

} else { 

int at = 

username^indexOf ("@") ; 


10 


if( at > 0) { 


username = 

username , substring ( 0, at ) ; 

15 bRet == login (appURL^ 

port, username, password) ; 

if (bRet) { 
state .put (SESSIONID, userSessionId) ; 
state.put (CONNECTURLSTR, url) ; 
20 state. put (CALENDARID, calendarld) ; 

} 

} 

} 

Log • log (Log •DEBUGGING, getClassO, . 
25 "########################### iPianet Username =" + 

username + "##############"); 

return bRet; 

} 

30 * Get a specific day's summaries from 

00:00:00 -> 23:59:59 

* (?param int year 

* @param int month 

* (?param int day 

35 


13499ROUS01U 92 

private String getSummaries (int year, int month, 
int day ) { 

log ("userSessionID = " + userSessionId) ; 
System. out .print { "year=" ) ; 
5 System.out .print (year) ; 

System.out .print ("month=") ; 
System. out. print (month) ; 

System.out .print ("day=") ; 
System.out .print (day) ; 
10 String strRetrieveSummary = 

retrieveSummaryString (userSessionId, year, month, 
day) ; 


return urlConnection (strRetrieveSummary, 
15 "Summary") ; 

} 

/★ * 

* Get a specific event based on session ID 
and event ID 

20 Sparam String session ID 

* @param String event ID 

private String getEvent (String sessionid. String 
eventid) { 

25 String strEvent = eventString ( sessionid, 

eventid) ; 

return urlConnection (strEvent, "Event"); 

} 

//http: //wleey00 6 : 81/login. wcap?user=wbin&password=ne 
30 w2day&ref resh=l&fmt~out=text/xml 

private String loginString (String url. String 
port. String user. String password) { 
StringBuffer buffer = new 
StringBuf f er (url) ; 


35 
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buf fer .append(" : ") .append (port) .append("/login.wcap?" 

); 

buffer. append ("user=") . append (user) . append ("&") .appen 
d { "password^" ) . append (password) ; 
5 buffer ♦ append ( " &ref resh=l &fint-out=text/xml " ) ; 

return buf f er . toString { ) ; 

} 

// 

http: //wleeyOOe : 81/ f etchevents__by_id. wcap?id=sessionI 
10 d&uid=eventId&rid=0&inod=l&calid=wbin&brief=0&fmt"-out= 
text/xml 

private String eventString (String sessionid. 
String eventid) { 

15 StringBuffer buffer = new 

StringBuffer(url) ; 

buf fer .append (": ") . append (port ) . append ( "/fetchevents__ 
by_id.wcap?") ; 

buf fer .append ("id=") . append (sessionid) . append ("&") .ap 
20 pend("uid=") , append (eventid) ; 

buf fer .append ("&rid=0") . append ( "&mod=l" ) . append (" &cal 
id=") .append (calendarld) ; 

25 buf fer .append ("&brief=0&fmt-out=text/xml") ; 

return buf fer .toString () ; 

} 

//http: //wleey006: 81/logout .wcap?id=n32nv9q3b2r5po32o 
30 q3&fmt-out=text/xml 

private String logoutString () { 
StringBuffer buffer = new 
StringBuf f er (url) ; 

buffer,append(" : ") . append (port) . append ( "/logout .wcap? 
35 "); 
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buffer, append ("id=") . append (userSessionid) ; 
buffer . append ( " &fmt-out=text/xnil " ) ; 
return buf f er . toString ( ) ; 

} 

5 //http://wleey006: 81/fetchcomponents_by_range.wcap?id 

=t9u9s6he2r5pu9b&dtstart=19990331T112233&dtend=200103 
31T112233&fmt-out=text/xml&raaxResults=0 


10 


15 


20 


//retrieve components from calendar 

private String retrieveSummaryString (String id, 
int year, int month, int day) { 

String start = getFormatedTime (year, month, 
day, 0, 0, 0) / 

String end = getFormatedTime (year, month, 
day, 23, 59, 59); 

StringBuffer buffer = new 
StringBuf f er (url) ; 

buffer. append (":") . append (port) .append ("/fetchcompone 
nts_by_range.wcap?") ; 

buffer. append ("id=") .append (id) ; 

buffer. append ("&dtstart=") . append (start ) . ap 
pend("&dtend=") .append (end) ; 

buffer . append ( " &f mt-out=text/xml&maxResult s=0" ) ; 

30 return buffer. toString 0 ; 

} 

/* 

http: //myserver : 81/ 

storecomponents.wcap?id=3423423asdfasf&calid=Johnl&dt 
35 start=19990101T103 


25 
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000&dtend=19990101T113000&uid=001&siiinmary-new__year_ev 
ent 


/ 


/* private String storeComponentString (String url. 
String port. String sessionid. String user. String 
password, 

10 String year, String month. String 

day. String eventid. String sximmary) { 

String start = getFormatedTime (year, month, 
day, 0, 0, 0) ; 

15 String end = getFormatedTime (year, month, 

day, 23, 59, 59); 

StringBuffer buffer = new 
StringBuf fer (url) ; 

20 buffer. append (": ") . append (port ) • append ( "/storecompone 

nts . wcap?id=" ) . append (sessionid) ; 

buffer. append ("&dtstart=") . append (start) ,ap 
pend ("&dtend=") .append (end) ; 

buffer.append("&uid=") . append (eventid) .appe 
25 nd("&summary=") .append (summary) ; 

return buf f er . toString ( ) ; 


30 */ 


http: //myserver: 81/storeevents.wcap?id='bu9p3eb8x5p2n 
35 m0q3 ' &calid=newcal 
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&uid=all_params&dtstart=19990811T093000Z&citend=l 99908 
11T163000Z 

5 

&suinmary=all%20params-of-storeevents%20are%20included 
£tlocation=Mountain-View&icsClass=conf idential 
10 &icsUrl= http : //www.mycompany . com 

&duration=PT7H&desc=read%20the%20suinitiary&status=0&isA 
llDay=l 

15 

&geo=37.39;- 

122 . 05&rrules="count%3D4%3Bf req%3Ddaily" ; "count%3D4%3 
Bfreq%3Dweekly" 

20 

&exrules="count%3Dl%3Bf req%3Dweekly%3Binterval%3D2%3B 
byday%3DTU%2CTH" 

25 &rdates=19991015T093000&exdates=19990813T0930006cprior 
ity=10 

&relatedTos=<777>&resources=board;projector&categorie 
S=MEETING 

30 

&contacts=Jane\, John&&alarmStart=l 99908 11T092500Z 

&alarmEmail=lucys@mycompany . com&orgEmail=j aneGmycompa 
ny, com; 

35 
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*/ 

/* private String storeEventString ( 

5 

String start = getFormatedTime (year, month, 
day, 0, 0, 0) ; 

String end = getFormatedTime (year, month, 
10 day, 23, 59, 59) ; 

return buffer.toStringO ; 

} 

*/ 


15 


25 


/ 


* urlConnection to Calendar server with 
20 given URL, callType 

* gparam String url for the server 


* @param String call type 


private String urlConnection (String strUrl, 
String call) { 

String retStr = null; 

30 try{ 

URL url = new URL(strUrl); 
//"http://wleey00 6,ca.nortel^coin: 81/login.wcap?user-w 
bin&password=new2day&refresh=l&fiut-out=text/xml") ; 

InputStream in = url .openStream ( ) ; 
35 BufferedReader bufReader 
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= new Buff eredReader (new 

InputStreamReader (in) ) ; 

// DatalnputStream data_in = new 

5 DatalnputStream (in) ; 

java.util .Vector contents = new 
j ava . ut il . Vector ( ) ; 

10 StringBuffer xmlString = new 

StringBuf f er ( ) ; 

PrintWriter output = null; 
String sessionLine = ""; 

15 

String loginLine = ""; 
String logoutLine = ""; 
StringWriter strout = new 

StringWriter ( ) ; 
20 if (call. equals ("Login") ) { 

//output = new PrintWriter (new 
Buff eredWriter (new FileWriter { "login. xml" ) ) ) ; 

output = new PrintWriter (strout) 

25 } 

if (call. equals ("Summary") ) { 

//output = new PrintWriter (new 
Buff eredWriter (new FileWriter ( "Summary .xml" ) } ) ; 
30 output = new PrintWriter (strout) 


35 


Summary .xml \n" ) ; 


//log ( "PrintWriter is created fo 
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10 


else { 

if (call. equals ("Event") ) { 

//output = new 
PrintWriter (new Buf f eredWriter (new 
FileWriterC "Event. xml") ) ) ; 


output = new 


PrintWriter (strout) ; 


15 


20 


25 


//log ("PrintWriter is 
created for Event •xml\n" ) ; 


null) { 
much if. 


} 


} 


String line ; 

boolean bflag = falser- 
while ((line = bufReader . readLine ( ) ) 1 

// Too dirty;, too 

log (line) ; 

contents. addElement (line) ; 
if (call . equals { "Login" ) ) { 
output .println (line) ; 


30 


if (line • startsWith ( "<X-NSCP-WCAP-SESSION-ID>" ) ) 

sessionLine = line; // 
found the line that contains sesssionID 

else 

if (line.startsWith {"<X-NSCP-WCAP-ERRNO>") ) 


35 


loginLine = line; 
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else if 

(line.indexOf {"<X-NSCP-WCAP-CALENDAR-ID>") >= 0) 

{ // get 

5 calendar ID 

int 

first == line^indexOf (">") + l; 

int 

last = line^lastlndexOf ("<") ; 
10 calendarld = line, substring (first;, last) ; 

log ("Calendar id =" + calendarld); 

} 

} 

else if( call, equals ("Event") ) 

15 

{ 

if 

(line.indexOf ("<START") >== 0) 

{ 

20 

bhasEvent = true; 

log ("processing <START> </START>") ; 

StringBuffer humanTime = new StringBuf f er () ; 

int 

25 last = line.indexOf {"</START>") ; 

String theTime = line , substring {7, last -1); 

log ("TimeString = " + theTime); 

theTime = ToHumanTime (theTime) ; 

humanTime . append ( "<APPDATE>" ) ; 
30 humanTime. append (curDate) ; 

humanTime , append ( "</APPDATE>" ) ; 

line 

= hvimanTime . toString ( ) ; 
output .println (line) ; 
35 humanTime = new StringBuf fer {) ; 
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hiamanTime . append { "<APPTIME>" ) ; 
humanTime. append (theTime) ; 
humanTime . append ( "</APPTIME>" ) ; 


10 


15 


20 


25 


line 


= humanTime. toString 0 ; 
output .println{ line) ; 


} 

else if 


(line.indexOf ("<END") >= 0) 
bhasEvent = true; 

log ("processing <END> </END>") ; 


StringBuffer humanTime = new StringBuf f er ( ) ; 

int 

last = line.indexOf ("</END>") ; 

String theTime = line . substring (5, last -1); 

log("TimeString = " + theTime); 

theTime = ToHumanTime (theTime) ; 

humanTime . append ( "<APPENDDATE>" ) ; 

humanTime. append (curDate) ; 

humanTime . append ( "</APPENDDATE>" ) ; 

line 

= humanTime . toString ( ) ; 


output .print In (line) ; 


30 humanTime = new StringBuf fer () ; 

humanTime . append ( "<APPENDTIME>" ) ; 
humanTime . append (theTime) ; 
humanTime . append ( "</APPENDTIME>" ) ; 


line 


Vz S 
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= humanTime. toString 0 ; 
output .println (line) ; 

else 

output •println (line) / 

5 } 

else if{ call. equals ("Suimnary") ) 

{ 

if 

(line.indexOf {"<EVENT") >= 0) 
10 bflag 
== true; 

if 

(line.indexOf ("</EVENT") >= 0) 

bflag 

15 = false; 

if (bflag 

line.indexOf ("<START") >= 0) 

{ 

20 bhasEvent = true; 

log ("processing <START> </START>") ; 

StringBuffer humanTime = new StringBuf fer () ; 

int 

25 last = line.indexOf ("</START>") ; 

String theTime = line • substring (7, last -1); 
log ("TimeString = " + theTime); 

30 

theTime = ToHumanTime (theTime) ; 
humanTime . append ( "<APPDATE>" ) ; 
hiimanTime * append ( cur Date ) ; 
humanTime • append ( "</APPDATE>" ) ; 
35 line 
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= h\amanTime.toString() ; 


output. println (line) ; 
hiJitianTime = new StringBuf f er ( ) ; 
humanTime . append ( "<APPTIME>" ) ; 
humanTime . append ( theTime ) ; 
humanTime . append ( "</APPTIME>" ) ; 

= humanTime. toString 0 ; 
output. print In (line) ; 

output .println (line) ; 


else if( 

call. equals ("Logout") ) { 

if (line . startsWith ( "<X-NSCP-WCAP-ERRNO>" ) ) 

20 

logoutLine 

= line; 


line 

} 

else 


25 


30 


retStr = strout. toString () ; 
output .close ( ) ; 

if ( call. equals ("Login") ) { 


loginLine = 

getValuedoginLine, "<X-NSCP-WCAP-ERRNO>" ) ; 


* > 
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if (loginLine. equals ("0") ) 


5 


10 


15 


20 


25 


30 


loginSucceed 
loginLine.equalsC'O")? true: false; 


if( loginSucceed) 

userSessionId = 
getValue(sessionLine, "<X-NSCP-WCAP-SESSION-ID>" ); 

//log ("User Session 
ID = " + userSessionId + " And loginSucceed=" -f 
loginSucceed) ; 

} 

/* 

if( call. equals ("Logout") ) { 
log ("Logout is 

executed") ; 

logoutLine = 

getValuedogoutLine, "<X-NSCP-WCAP-ERRNO>") ; log("Th< 
logout line is : " + logoutLine); 


logoutSucceed = 
logoutLine.equals("-l") ? true: false; 

} 

*/ 

bufReader. close 0 ; 

// log(retStr); 
return retStr; 
} catch (Exception ex) { 
} 

return null; 

35 } 


13499ROUS01U 105 

* getValue to get session ID from input line 
5 * gparam String line containning session ID 

* ©return String session ID 

public String getValue (String selectedLine, 
string tag) { 

String idString = null; 

try { 

//X-NSCP-WCAP-SESSION-ID> 

//X-NSCP-WCAP-ERRNO 

//String temp = 
"<X-NSCP-WCAP-SESSION-ID>" ; 

25 idString = 

selectedLine.substring (tag, length () ) ; // get 
substring after <> 

idString = idString • substring (0, 
30 idString • indexOf ('<')); 

} 

catch ( Exception e ) { 


10 


; r'5 


;*5 s 


15 


•SWT 


20 


35 


e .printStackTrace ( ) ; 
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} 

return idString* trim() ; 


} 

5 private String getFormatedTime (int year, int 

month, int day, int hour, int minute, int second) { 


StringBuffer dateTime = new 
StringBuf f er (""+year) ; 
10 if (month< 10) { 

dateTime. append ("0") ; 

} 

dateTime. append (month) ; 
if (day<10) { 

15 

dateT ime . append ( " 0 " ) ; 


20 dateTime. append (day) . append ("T") 


if ( hour< 10) { 


dateT ime. append ("0") ;// 

25 } 

dateTime . append (hour) ; 
if { minute<10) { 

dateTime. append ("0") ; // 

} 

30 dateTime . append (minute) ; 

if ( second<10) 

dateTime. append ("0") ;// 
dateTime . append ( second) ; 
log ("The time is =: "+dateTime.toString () ) 
35 return dateTime . toString () ; 
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} 

* login (String, String, String, String) in 
the calendar with 
5 * @param String url of Calendar server 


* @param String port of the Calendar server 

* @param String usernaiae 

* @param String password 


10 


15 


20 


* ©return boolean true login succeed, false 
means you are not lucky, 

private boolean login (String url, String 
port. String user. String password) { 

this •url = url; 

this .port = port; 


25 String strLogin = loginString (url, 

port, user, password) ; 

log (strLogin) ; 
// login 

30 try{ 

urlConnection ( strLogin, "Login" ) 
log ("User session ID = " + 

userSessionId) ; 

return loginSucceed; 
35 } catch (Exception ex) { 
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ex.printStackTrace () ; 
return false; 
} finally! 

// what should be put here.? 

5 } 

} 

* Convert Calendar Date in Start and End 
elements into speakable date 

10 ^ gparam String dateStr 

20000909T17000000 to September 9, 2000 

private String ToHnmanDate (String theDate) 
{ 

15 StringBuffer dateBuf == new 

StringBuf fer () ; 

Integer year, month, day; 
year = new Integer ( 
20 theDate. substring (0, 4)); 

month = new Integer ( 
theDate • substring (4, 6) ) ; 

25 day = new Integer ( 

theDate , substring (6, 8 ) ) ; 

log ("ToHumanDate dateStr: " + 

theDate) ; 


30 


dateBuf • append (monthStr [month . intValue ( ) - 1 ] ) ; 


35 


dateBuf . append { " 
") .append (day) .append ") * append (year ) ; 
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log ("Converted Date: " + 
dateBuf . toString ( ) ) ; 

return dateBuf .toString () ; 


/ 


* Convert the time in the START element into 
10 speakable time 

* Such as 20000911T150000Z to 8 i^M On 
Spetember 11, 2000 

V 

15 private String ToHumanTime (String theDate) 


{ 


20 log ("ToHumanTime&&&&&&&&&&&&&&&&&&&&6c&&&& ; 

log ("theDate =" + theDate); 

Calendar localTime = 
25 Calendar .getlnstance (TimeZone.getDefault 0 ) ; 

int GMToffset = 
localTime. get (Calendar .ZONE__OFFSET) / 3600000; 

30 System. out. print ("GMT offset = "); 

Integer yearl, monthl, dayl, hourl, 
minute 1, secondl; 

35 int year, month, day, hour, minute. 


13499ROUS01U HO 

second; 


yearl = new Integer { 
theDate. substring (0, 4) ) ; 

monthl = new Integer ( 
theDate, substring (4, 6) ) ; 


10 


15 


20 


25 


30 


dayl = new Integer ( 
theDate • substring (6, 8 ) ) ; 

hourl == new Integer ( 
theDate. substring (9, ii) ) ; 

minutel = new Integer ( 
theDate. substring (11, 13) ) ; 

secondl = new Integer { 
theDate. substring (13, 15) ) ; 

year = yearl . intValue () ; 
month = monthl . intValue ( ) ; 
day = dayl. intValue 0 ; 


GMToffset; 


hour = hourl. intValue 0 - i 


35 


minute = minutel . intValue ( ) 

second = secondl . intValue ( ) 

if (hour < 0) 

{ 

hour += 24; 
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day — ; 


10 


15 


20 


25 


30 


35 


if (day < 0) 
{ 

month — ; 
if (month < 0) 
year — ; 

} 

} 

else if (hour > 24) 

hour -= 12; 
String timeTag = "AM"; 

Integer dayint = new Integer (day) ; 
String dayStr = dayint. toString () ; 
Integer yearint = new Integer (year) ; 
String yearStr = yearint . toString () ; 
if (hour > 12) 


timeTag = "PM" ; 
hour -= 12; 


else if (hour == 12) 

timeTag = " "; 
StringBuffer timeStr = new 
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StringBuf f er 0 ; 

timeStr .append (toString (hour) ) ; 
5 if (minute > 0) 

timeStr .append (": ") .append (toString (minute) ) ; 

if (second > 0) 

10 

timeStr .append(" : ") , append (toString (second) ) ; 

timeStr .append (" ") . append (timeTag) 
15 localTime. set (Calendar .YEAR, year) ; 

localTime. set (Calendar .MONTH, month 

1) ; 

20 localTime .set (Calendar .DAy_OF__MONTH 

day) ; 

Date date = localTime . getTime () ; 

SimpleDateFormat fd = new 
25 SimpleDateFormat ("EEEE, MMMMMMMMM d, yyyy"); 

curDate = fd. format (date) ; 

// log ( "converted time: " + 

30 timeStr. toString 0 + " " + curDate); 

return timeStr .toString () / 

} 

private String toString (int value) 
{ 

35 Integer tmpvalue - new 
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Integer (value) ; 

return new 
String ( tmpvalue . toS tr ing ( ) ) ; 

5 } 


10 


logout 0 of the Calendar 
*/ 

public void logout (){ 


String strLogout = logoutString { ) ; 
log (strLogout) ; 


urlConnection (StrLogout, "Logout") ; 
/ /return logoutSucceed; 

} 

private void log (String s) 

{ 

Log. log (Log. DEBUGGING, getClassO, s) ; 

} 


20 


25 


30 


} 


35 


Fig 3 illustrates a full-blown system 
according to the invention including a session 
manager 80 and an authentication manager 90. The 
figure illustrates the different components of the 
full system as described above. It can be seen that 
the authentication manager 90 is shown as having 
multiple servlets within it. This is because each 
device type has a separate authentication servlet to 
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accommodate the needs of that specific device type. 
Similarly/ the DMI component 40 has multiple servlets 
within it — one servlet for each device type. The 
broker module 30 is shown as two components - the 
5 software MCML script 30A and the finite state machine 

XML/XSLT engine SOB which executes the script 3GA, 
The AMI component 20 is depicted as two components — 
as application EJBs and authentication EJBs. Each 
group of EJBs has its specific function* The 

10 application EJBs provide the data to the broker 

module while the authentication EJBs provide the 
authentication data required by the authentication 
manager. The authentication EJBs also access the 
applications but only to the extent required by the 

15 authentication manager. 

Also/ as can be seen in Fig 3, the end user 
devices communicate with an extra layer between 
itself and the authentication manager. For WAP 
enabled devices, a WAP gateway lOOA receives their 

20 data. For a PSTN telephone 50C, the user's voice 

first goes through a Voice XML engine lOOB which 
converts the user's voice input into data 
recognizable by the other components. A dispatch 
servlet 110 sends the signals to their proper servlet 

25 in the authentication manager. 

For a regular PC 70, its authentication 
data has to travel through the APM (access policy 
manager) authorization server 120 and then to the 
LDAP (lightweight directory access protocol) server 

30 130. 

To step through the process, the PSTN 
telephone, if its user desires access to an 
application, the sequence of steps are as follows : 
1 , User dials up Voice Portal DN using a 

35 POTS phone 
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Voice Portal static welcome page is 
invoked, and the server makes a request to 
the authentication servlet via the initial 
URL* 

Authentication servlet does not see a 
session key embedded in the request URL and 
therefore issues a challenge page 
appropriate to the device* It does this by 
checking the user agent type and other 
information in the request header^r and^by 
then fetching an MCML document that it 
translates through the appropriate XSL 
style sheet - which produces a Voice XML 
form, welcoming the user and asking for 
authentication (user id and password) . The 
links in this Voice XML document have a 
temporary authentication key embedded in 
them by the authentication servlet^^ to 
protect this initial transaction. 

Voice Portal begins to interpret the 
Voice XML script, which asks for the 
initial welcome prompt and login request. 
User listens to welcome prompt and to the 
request for user id, and keys in or speaks 
the requested info (we can set this choice 
either way through Voice XML tags) • 

Voice Portal then interprets the user 
input and sends a request to the 
authentication servlet with the posted form 
data. The authentication servlet checks 
with APM and authenticates the user* If 
successful, it generates a session ID that 
will be appended to all subsequent 
transaction URLs with our server for this 
session. 
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6. The authentication servlet continues 

to interpret the PIC MCML flow, which asks 
it to call the PIC EJB, to get a list of 
enabled applications from the 
Personalization Server. 

I . The EJB returns the list, filtered by 
the EJB adaptor into MCML, which is 
embedded into the PIC MCML template. 

8. The list has associated hyperlink URLs 

that are filtered through the session 
manager, to append a session ID (URL 
rewriting) . 

9* The MCML is translated to Voice XML by 

the XSLT processor using the VoiceXML style 
sheet. It is then served to the Voice 
Portal for interpretation. 

10. The user hears the list (TTS) and 

selects an application. This causes the 
Voice Portal to send an HTTP request to the 
authentication servlet . 

II, The servlet now sees a session ID 
appended to the URL, and checks its 
validity. If valid, it passes the request 
on to the device adaptor servlet (DA) , 
unchallenged, 

12. The DA then retrieves the MCML page 
for that particular app, (this was encoded 
in the request URL) . 

13. It scans for dynamic placeholder tags, 
and makes calls to the application specific 
adaptor EJB's (method names and parameters 
are embedded in MCML) to generate dynamic 
application content if required. 

14. The device adaptor EJB attempts to 
retrieve a client connection to the app. 


117 

from the Session Manager. 

15. The session manager cannot find the 
client, and throws an exception, which is 
passed on the DA. 

16. The DA identifies this exception and 
invokes the authentication EJB associated 
with this app. which connects using the 
stored credentials, and then saves a client 
connection in the Session manager (Single 
sign-on) . 

17. The device adaptor then re-tries the 
initial call to the application adaptor, 
which will now successfully retrieve the 
client connection from the session manager. 

18. The EJB connects to the app to get 
content . 

19. This content is returned by the EJB' s 
as MCML, through the EJB-DA interface 
object, which converts the data to MCML. 
The DA merges this MCML with the static 
MCML page template. 

20* The DA then filters all URLs through 

the Session manager to append session ID. 
The link to the next MCML page is also 
generated and appended to the URLs here. 

21. The DA then translates the MCML though 
XSLT to get a Voice XML, which is served 
back to the client. 

22. Voice Portal client interprets the 
returned page, and cycles through the 
process starting at step 11 above (without 
the initial authentication exceptions) , 
invoking further MCML pages. 

23. The cycle continues until the MCML FSM 
script reaches an exit state, at which 
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point the DA closes the connection by 
deleting the session - by making a call to 
the Session manager. Further requests will 
then require the authentication cycle to 
5 kick-in. User inactivity time-outs can also 

occur if the user hangs up, or fails to 
respond within a prescribed delay. 
For a WAP enabled cellular telephone or a 
WAP enabled PDA, the process is as follows : 
10 1. User accesses WAP gateway via Remote Access 

Server dialup programmed into the WAP handset. User 
selects a link to access the multi-channel system. 
2, As a result, WAP gateway makes a request to 

the authentication servlet. 
15 3. Authentication servlet does not see a 

session ID embedded in the request URL and 
therefore issues a challenge page appropriate to 
the device. It does this by checking the user agent 
type in the header, and by then fetching an MCML 
20 document that it translates through the appropriate 

XSL style sheet - which produces a HDML or WML 
deck, welcoming the user and asking for 
authentication (user id and password) . The links in 
this document have a temporary authentication key 
25 embedded in them by the authentication servlet, to 

protect this initial transaction. Care must be 
taken not to exceed the limitations on URL size 
inherent to some WML and HDML browsers . 
4. The handset browser displays the card deck, 

30 which asks for the initial welcome prompt and login 

request. User keys in credentials. These are sent 
through WAP gateway as a request to the 
authentication servlet with the posted form data. 
The authentication servlet checks with APM and 
35 authenticates the user. If successful, it generates 
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a session ID that will be appended to all 
subsequent transaction URLs with our server for 
this session. 

5. The authentication servlet continues to 

5 interpret the PIC MCML flow, which asks it to call 

the PIC EJB, to get a list of enabled applications 
from the Personalization Server. 

6. The EJB returns a list of application, 
filtered by the EJB adaptor to produce MCML, which 

10 is embedded into the PIC MCML template, 

7. The list has associated hyperlink URLs that 
are filtered through the session manager, to append 
a session ID (URL rewriting) . 

8. The MCML is translated to WML or HDML by 
15 the XSLT processor using the appropriate style 

sheet. It is then served to the WAP gateway for 
forwarding to the handset, 

9. The user sees the list and selects an 
application. This causes the WAP gateway to send a 

20 HTTP request to the authentication servlet. 

10. The servlet now sees a session ID appended 
to the URL, and checks its validity. If valid, it 
passes the request on to the device adaptor servlet 
(DA) , unchallenged. 

25 11. The DA then retrieves the MCML page for 

that particular app. (this was encoded in the 
request URL) . 

12. It scans for dynamic placeholder tags, and 
makes calls to the application specific adaptor 

30 EJB's (method names and parameters are embedded in 

MCML) to generate dynamic application content if 
required. 

13. The device adaptor EJB attempts to retrieve 
a client connection to the app. from the Session 

35 Manager. 
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14* The session manager cannot find the client^r 

and throws an exception, which is passed on the DA, 
15 • The DA identifies this exception and 


invokes the authentication EJB associated with this 
5 app, which connects using the stored credentials, 

and then saves a client connection in the Session 
manager (Single sign-on) . 
16, The device adaptor then re- tries the 

initial call to the application adaptor, which will 
10 now successfully retrieve the client connection 

from the session manager* 
17 • The EJB connects to the app to get content, 

18, This content is returned by the EJB' s as 
15 MCML, through the EJB-DA interface object, which 

converts the data to MCML. The DA merges this MCML 
with the static MCML page template, 

19, The DA then filters all URLs through the 
Session manager to append session ID. The link to 

20 the next MCML page is also generated and appended 

to the URLs here. 

20, The DA then translates the MCML though XSLT 
to get WML a HDML deck, which is served back to the 
client . 

25 21. WAP gateway forwards the returned deck to 

handset, and cycles through the process starting at 
step 10 (but omitting any initial authentication 
exceptions) above, invoking further MCML pages. 
22, The cycle continues until the MCML FSM 

30 script reaches an exit state, at which point the DA 

closes the connection by deleting the session - by 
making a call to the Session manager. Further 
requests will then require the authentication cycle 
to kick-in. User inactivity time-outs can also 

35 occur if the user disconnects, or fails to respond 
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within a prescribed delay. 

A person understanding the above-described 
invention may now conceive of alternative designs, 
using the principles described herein. All such 
5 designs which fall within the scope of the claims 

appended hereto are considered to be part of the 
present invention . 


